developer.tipsAndTricks

From autoplot.org

Jump to: navigation, search

Purpose: Serve as the one place where we keep tips and tricks about developing Autoplot.

Audience: Jeremy, the senior developer, and others who want to get into the code.

Contents

  1. replicating hudson tests
  2. misc
  3. Breakpoints that don't stop
  4. Remote Debugging
  5. Remote Debugging Non-Webstart
  6. Breakpoint when a message is displayed
  7. Logging
  8. Open Files
  9. Event Thread Response Monitor
  10. Getting the Stack Trace of a Hung Process

1. replicating hudson tests

I just found this a handy way to replicate what the hudson tests are doing. Often I'm running things interactively, and the bug won't show.

load( 'file:///home/jbf/ct/hudson/vap/autoSlice.vap' )
writeToPng('/tmp/foo.png')

2. misc

It's much quicker to pick up most of the leaves than every last leaf.

3. Breakpoints that don't stop

I was just able to debug a nice case where a thread race would cause the events renderer to not paint by putting in two breakpoints that don't stop execution but are reported in the Netbeans Debugger Console. I could verify it was reaching one part of the code but not another.

4. Remote Debugging

I was using Webstart to answer an email, when the application hung. I'd love to be able to jump into it and see where all the threads were, so I reminded myself how to do remote debugging on Linux with Webstart (and Bash):

  • from the linux command line, type "jcontrol"
  • On the "Java" tab (of General, Java, Security and Advanced), click "View..." button.
  • Add "-Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=y" to the Runtime Parameters of the correct Java.
  • In Netbeans, pointing at the correct source version, use Debug->Attach Debugger to connect to the process.
  • Webstart will start as normal

This worked without trouble, and would also work remotely (provided there are no firewalls blocking.)

20150521: This is not working for me, and is acting like I'm debugging the webstart part but not the Autoplot part that is handed control. Okay--looks like you have to attach it, then it looses it's connection, but "telnet localhost 12345" shows the debugger port is still open. Simply attach Netbeans again and it works.

20160131: I have not been able to get this to work for a while. I tried different combinations of javaws -offline but this does not help. I did a bit of searching and found the only way I could do this is via the java control panel:

  • from the linux command line, type "jcontrol"
  • On the "Java" tab (of General, Java, Security and Advanced), click "View..." button.
  • Add "-Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=y" to the Runtime Parameters of the correct Java.

20160815: I confirmed that the 20160131 method works, however it is complaining that it was compiled without the -g option.

5. Remote Debugging Non-Webstart

Same as with Webstart, but:

  • java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=12345,suspend=y -cp autoplot.jar org.virbo.autoplot.AutoplotUI

6. Breakpoint when a message is displayed

Often we get a message in the console, like "null" or "DEPEND_1 found but data is lower rank" and we want to see where it's coming from. Turn on the log console, and in the console settings turn on "highlite lines matching" to the string. Then in the debugger, put a breakpoint in LogConsole.java in the getHandler publish method, look for "breakpoint here for debugging".

7. Logging

  • HOME/autoplot_data/config/logging.properties is always read. (20150131c,v2015a_2)

8. Open Files

To see what files is Autoplot leaving open, get the PID from the title bar of a development version (or the about screen), and do:

PID=<pid>
ls -l /proc/$PID/fd | grep -v '.jar$' | grep -v '.ttf$' | grep -v 'random$'| grep -v 'socket:' | grep -v 'pipe:' | grep -v 'anon_inode:'

9. Event Thread Response Monitor

The response monitor is a system which regularly fires off events and measures the amount of time they take to propagate though the event system. When a long process is performed on the event thread, it will hang the application, and to correct this, a new thread should be created and monitored with a progress bar (monitor object, org.das2.util.monitor), and then the event thread can be freed should immediately return.

The Event Thread Response Monitor (ETRM) is enabled either by using ~/autoplot_data/config/system.properties, which should contain "enableResponseMonitor=true", or by using the command line switch --enableResponseMonitor (versions after 20170507). It works by regularly queuing dummy events, and then checking to see if the dummy event is still on the event queue after 10 seconds. An RTE "hang" file that show the .vap and the state of each of the threads will be written to ~/autoplot_data/log/hang_*_xml.

The ETRM can be manually triggered, writing a hang file of the current state to ~/autoplot_data/log/hang_*_xml. If the empty file "~/autoplot_data/log/request_dump.txt" is created, this will be deleted within seconds and a hang file is created. Note this may cause some security concerns, so make sure ~/autoplot_data/log/ is writable by trusted people. The hang files created using this mechanism are only readable by the scientist running Autoplot.

10. Getting the Stack Trace of a Hung Process

Using "kill -3":

PID=`ps -ef | grep autoplot | grep jre | awk '{print $2}'`
kill -3 $PID   

This will not destroy the process, but tells it to dump the stack information. Look in the console where the Java process was run.

Or, better yet use jstack:

jstack PID > outfile

When that doesn't work, try:

PID=`ps -ef | grep autoplot | grep jre | awk '{print $2}'`
rm -f xxx.hprof
jmap -dump:format=b,file=xxx.hprof $PID

and open "xxx.hprof" in Netbeans.

See the previous section as well, which is a mechanism which when enabled makes this easier.

Personal tools