JDK-6289830 : Monitors entered by JNI MonitorEnter aren't freed after thread quits normally
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-06-23
  • Updated: 2017-05-16
  • Resolved: 2005-12-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 betaFixed
Related Reports
Relates :  
JDK-6448027 - com.sun.jdi.ThreadReference.ownedMonitorsAndFrames() returns unexpected monitor
Relates :  
JDK-6282335 - DetachCurrentThread doesn't release monitors was taken by MonitorEnter (doc change)
Description
This is very similiar to 6282335. But in this case thread can't be detached because of java frames in stack. It quits normally and native monitor isn't automatically freed. JNI spec says that DetachCurrentThread should free monitors, but normal exiting from java thread shouldn't be the worst case. 
See attach test code for details.
###@###.### 2005-06-23 10:41:35 GMT
Comments
EVALUATION JNI spec was updated to note that attached threads must call DetachCurrentThread before exiting. A successful DetachCurrentThread call will cause JNI-acquired monitors to be released normally.
15-12-2005