We got a lot of people using our milestones of JBoss Tools and Developer Studio and I get asked from time to time how to best report on issues they spot/find. I've started this article to outline some of the tips & tricks around this.
Note: I’m not covering “obvious” things like actually opening a bug in jira, take screenshots and do what you can to write down the minimal steps to reproduce it and provide information like which version, OS etc. you are using - this article is about getting access to more internal details of Eclipse/Java to help.
When something fails in Eclipse it is very likely it’s log file has information about what caused the problem.
The log file is located in /.metadata/.log.
Eclipse.org has more info about this file at http://wiki.eclipse.org/FAQ_Where_can_I_find_that_elusive_.log_file%3F
In JBoss Tools we’ve made it even simpler to gather this file and a few other pieces of information in a zip file.
Help > Report a problem and a dialog will show up where you can fill in details of what caused the problem. When you press ‘Finish’ a .zip file will be generated which contains the log file, Eclipse system properties and your comment.
You can attach this zip file to the related jira issue.
Freezes or slowness
In case Eclipse freezes or some operation is taking exceedingly long time to complete getting a thread dump is immensly useful. Luckily recent versions of Java comes with two tools that help makes this a breeze to get:
jps/jstack in short
jps -v jstack <pid found via jps> > <jira-id>.dump.txt
Attach the .txt file to the related jira.
jps provides you with info about the java process id of the virtual machines running on your machine.
Here is what
jps shows on my machine currently:
[max@greybeard ~]$ jps 255 261 2295 264 4734 Jps 4381 3261
In many cases you don’t have that many processes running and can easily guess which one is the one you are looking for (Tip: the higher the number, the newer the process).
In case you want to get some more details you can use
jps -v to get more details, here is as small snippet of what it shows for me:
[max@greybeard ~]$ jps -v 255 -Dosgi.requiredJavaVersion=1.5 -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -XX:MaxPermSize=256m -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Xms40m -Xmx512m -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts 4869 Jps -Dapplication.home=/Library/Java/JavaVirtualMachines/1.6.0_26- b03-383.jdk/Contents/Home -Xms8m[max@greybeard ~]
This should give you enough details to pin down which process you are looking for.
Once you found it note down the process id - in my case above it is 255.
Then you use
jstack <pid> to get the threaddump, below is a small snippet of how that will look like:
[max@greybeard ~]$ jstack 255 2011-10-26 10:10:31 Full thread dump Java HotSpot(TM) Client VM (20.1-b02-383 mixed mode): "Attach Listener" daemon prio=9 tid=0000000003b8b400 nid=0xb1731000 waiting on condition  java.lang.Thread.State: RUNNABLE "Worker-52" prio=5 tid=0000000003e83400 nid=0xb20c7000 in Object.wait() [00000000b20c6000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:188) - locked <00000000084188a0> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:220) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50) "Worker-50" prio=5 tid=000000000366e400 nid=0xb26d5000 in Object.wait() [00000000b26d4000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:188) - locked <00000000084188a0> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:220) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50)
This content is what we would be interested in.
To get it to us the simplest thing is to pipe it to a file and attach it to the jira.
Tip: put the jira ID into the name of the file for easy identification/tracking.
jstack 255 > JBIDE-12345.dump.txt