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 <_0x60a1e90 /> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
        at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:461)
        - locked <_0x60a1e90 /> (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=0x00034c90 nid=0xaac waiting on condition [0..7fc3c]
...

"VM Thread" prio=5 tid=0x00505cf0 nid=0x1804200 runnable 

"VM Periodic Task Thread" prio=10 tid=0x00508070 nid=0x1815400 waiting on condition
"Exception Catcher Thread" prio=10 tid=0x00500de0 nid=0x1803e00 runnable 

Found one Java-level deadlock:
=============================
"test2":
  waiting to lock monitor 0x004c17c3 (object 0x10213a38, a [I),
  which is held by "test1"
"test1":
  waiting to lock monitor 0x004c17a3 (object 0x10213a48, 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