Hi,
I came across a set of commands on the new JPDA-based jdb that provide powerful tools to debug deadlocks and other thread related issues - as well as providing the basis for nice extensions to JDEbug:
lock <expr> -- print lock info for an object
threadlocks [thread id] -- print lock info for a thread
I had to try many combinations until I get them to work, for they are - as I found out after trial and error - VM dependent. They are not supported by the Hotspot VM's; you have to specify -classic.
I created a test application (attached) that creates a canonic deadlock between two threads. Them I started the application with the following parameters:
/cygdrive/d/dev/deadlock> d:/bin/jdk1.3.1/bin/java -classic -Xnoagent -Djava.compiler=NONE -Xdebug '-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000' -classpath "d:/dev/deadlock;d:/bin/jdk1.3.1/lib/jvm.jar;d:/bin/jdk1.3.1/lib/tools.jar;d:/bin/jdk1.3.1/lib/dt.jar;d:/bin/jdk1.3.1/lib/ir.jar" Deadlock
Starting threads
Joining
Deadlock-1 got lock 1
Deadlock-2 got lock 2
The application stars and immediately blocks due to the deadlock. Then I started jdb:
/cygdrive/d/bin/jdk1.3.1/bin> ./jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8000
Here is a small session that illustrates the use of "threadlocks":
Initializing jdb...
> threads
Group system:
(java.lang.Thread)0x3 Signal dispatcher running
(java.lang.ref.Reference$ReferenceHandler)0x4 Reference Handler cond. waiti
(java.lang.ref.Finalizer$FinalizerThread)0x5 Finalizer cond. waiti
Group main:
(java.lang.Thread)0x1 main cond. waiti
(java.lang.Thread)0xa Deadlock-1 waiting in
(java.lang.Thread)0xb Deadlock-2 waiting in
> suspend
All threads suspended.
> threadlocks 0xb
Monitor information for thread Deadlock-2:
Owned monitor: instance of java.lang.Object(id=12)
Waiting for monitor: instance of java.lang.Object(id=14)
> threadlocks 0xa
Monitor information for thread Deadlock-1:
Owned monitor: instance of java.lang.Object(id=14)
Waiting for monitor: instance of java.lang.Object(id=12)
> threadlocks 0x1
Monitor information for thread main:
No monitors owned
Not waiting for a monitor
It is easy to see that there is a deadlock by checking the ownership of monitors in the lines above. I couldn't find a way to correlate the monitor id (id=12 and 14) to actual variable names, but dumping the stack trace of the threads helps:
Deadlock-2[1] where
[1] Deadlock$2.run (Deadlock.java:51)
[2] java.lang.Thread.run (Thread.java:484)
I hope this information is helpful. It would be neat to see a command like that available on the JDEbug Threads buffer.
Regards,
Nascif
Deadlock.java