JDK-6448027 : com.sun.jdi.ThreadReference.ownedMonitorsAndFrames() returns unexpected monitor
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2006-07-12
  • Updated: 2012-08-23
  • Resolved: 2012-08-23
Related Reports
Relates :  
JDK-6282335 - DetachCurrentThread doesn't release monitors was taken by MonitorEnter (doc change)
Relates :  
JDK-6289830 - Monitors entered by JNI MonitorEnter aren't freed after thread quits normally
Description
Attached test reproduces bug found during execution multiple JDI tests in single VM.

Test scenario:
Fisrt, debuggee VM starts thread with name "TestThread1" which acquires monitor with JNI MonitorEnter and finishes, then debugger starts second thread with name "TestThread2" which just executes infinite loop. Debuggeer first print data obtained for "TestThread1" and then print data obtained for "TestThread2" and for both threads method ownedMonitorsAndFrames() returns the same monitor and this is wrong for "TestThread2" which doesn't acquire any monitor.

Bug reproduces intermittently.

Test output:

debuggee out>>>Command received: createThread1
Thread: instance of OwnedMonitorsDebuggee$Thread1(name='TestThread1', id=151)
Total monitors: 1
Monitor: instance of java.lang.Object(id=155) Thread: instance of OwnedMonitorsDebuggee$Thread1(name='TestThread1', id=151) Depth: -1
debuggee out>>>Command received: createThread2
Thread: instance of OwnedMonitorsDebuggee$Thread2(name='TestThread2', id=158)
Total monitors: 1
Monitor: instance of java.lang.Object(id=155) Thread: instance of OwnedMonitorsDebuggee$Thread2(name='TestThread2', id=158) Depth: -1
Unexpected monitors was returned for TestThread2
debuggee out>>>Command received: QUIT
debuggee out>>>Exit
TEST FAIL
Comments
EVALUATION I agree with Dean that it is not a bug. The test is doing weird thing. It should release the monitor with the MonitorExit in Thread1. I'm closing this as "Not a defect". But even if one would insist it is a bug then it is not a JVMTI bug. :)
23-08-2012
EVALUATION seem to be a test error? who owns these tests?
14-05-2012
EVALUATION The Java SE 7 JNI spec says: "To avoid deadlocks, a monitor entered through a MonitorEnter JNI function call must be exited using the MonitorExit JNI call, unless the DetachCurrentThread call is used to implicitly release JNI monitors." so this is a bug in the attached test.
28-03-2012
EVALUATION Objects locked by JNI are not unlocked on normal thread exit (see also 6289830). If one Thread exits, its JavaThread * will be freed and that memory can end up as the JavaThread * of a new Thread. Then JVMTI can show the monitor that was locked by the first thread as being owned by the second thread. This is because JNI monitors are on a global list and associated with a particular thread based on the owner() which is a JavaThread *.
28-03-2012
EVALUATION The thread exit should have cleaned the native monitors. Looks like thread2 is using the thread1 resources so the monitor held by thread1 is showing up on thread2. This is hotspot bug so moving to hotspot jvmti.
12-07-2006