Torsten Curdt’s weblog

How come I missed that for so long! If you kill your jvm with “kill -3 PID” you get a full thread dump that even shows deadlocks!

Full thread dump Java HotSpot(TM) Client VM (1.4.2-38 mixed mode):

"worker#9" prio=5 tid=0x0054de90 nid=0x195ea00 in Object.wait() [f1193000..f1193b20]
	at java.lang.Object.wait(Native Method)
	- waiting on <_0×60a1e90 /> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
	at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:461)
	- locked <_0×60a1e90 /> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
	at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnection(MultiThreadedHttpConnectionManager.java:365)
	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:613)
	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497)
"main" prio=5 tid=0×00034c90 nid=0xaac waiting on condition [0..7fc3c]
…

"VM Thread" prio=5 tid=0×00505cf0 nid=0×1804200 runnable 

"VM Periodic Task Thread" prio=10 tid=0×00508070 nid=0×1815400 waiting on condition
"Exception Catcher Thread" prio=10 tid=0×00500de0 nid=0×1803e00 runnable 

Found one Java-level deadlock:
=============================
"test2":
  waiting to lock monitor 0×004c17c3 (object 0×10213a38, a [I),
  which is held by "test1"
"test1":
  waiting to lock monitor 0×004c17a3 (object 0×10213a48, a [I),
  which is held by "test2"

Java stack information for the threads listed above:
============================================
"test2":
        at org.vafer.Worker.two(Worker.java:23)
…

"test2":
        at org.vafer.Worker.one(Worker.java:16)
…
Found 1 deadlock.

5. July 2005 | java | DiggIt!