# developer.tipsAndTricks

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.

# 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 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).