JDK-8071813 : assert(false) failed: Non-balanced monitor enter/exit! Likely JNI locking
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux
  • CPU: x86
  • Submitted: 2015-01-28
  • Updated: 2021-06-15
  • Resolved: 2016-01-26
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 9
9Resolved
Related Reports
Relates :  
JDK-8213825 - assert(false) failed: Non-balanced monitor enter/exit! Likely JNI locking
Relates :  
JDK-8268347 - C2: nested locks optimization may create unbalanced monitor enter/exit code
Description
Current thread (0xc2d38800):  JavaThread "Thread-1" [_thread_in_Java, id=10195, stack(0xc2c02000,0xc2c53000)]

Stack: [0xc2c02000,0xc2c53000],  sp=0xc2c51ab0,  free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1053718]  VMError::report_and_die()+0x198;;  VMError::report_and_die()+0x198
V  [libjvm.so+0x6e0b06]  report_vm_error(char const*, int, char const*, char const*)+0x76;;  report_vm_error(char const*, int, char const*, char const*)+0x76
V  [libjvm.so+0xd76682]  ObjectMonitor::exit(bool, Thread*)+0x892;;  ObjectMonitor::exit(bool, Thread*)+0x892
V  [libjvm.so+0xf75977]  ObjectSynchronizer::slow_exit(oop, BasicLock*, Thread*)+0x87;;  ObjectSynchronizer::slow_exit(oop, BasicLock*, Thread*)+0x87
V  [libjvm.so+0xed9ea1]  SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*)+0x131;;  SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*)+0x131
J 450 C2 java.util.logging.LogManager.setLevelsOnExistingLoggers()V (160 bytes) @ 0xedeffa9f [0xedefd020+0x2a7f]
J 397 C1 java.util.logging.LogManager.readConfiguration(Ljava/io/InputStream;)V (191 bytes) @ 0xe62852e4 [0xe6283a00+0x18e4]
J 391 C1 java.util.logging.LogManager.readConfiguration()V (269 bytes) @ 0xe628a268 [0xe6287f40+0x2328]
j  TestLogConfigurationDeadLock$ReadConf.run()V+9
v  ~StubRoutines::call_stub
V  [libjvm.so+0x99100e]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x205e;;  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x205e
V  [libjvm.so+0xd9ef14]  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x24;;  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x24
V  [libjvm.so+0x98bf43]  JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x633;;  JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x633
V  [libjvm.so+0x98c86d]  JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x9d;;  JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x9d
V  [libjvm.so+0xa7cff4]  thread_entry(JavaThread*, Thread*)+0xc4;;  thread_entry(JavaThread*, Thread*)+0xc4
V  [libjvm.so+0xfcb112]  JavaThread::thread_main_inner()+0x202;;  JavaThread::thread_main_inner()+0x202
V  [libjvm.so+0xfcb466]  JavaThread::run()+0x2e6;;  JavaThread::run()+0x2e6
V  [libjvm.so+0xd96660]  java_start(Thread*)+0x100;;  java_start(Thread*)+0x100
C  [libpthread.so.0+0x5e72]  start_thread+0xd2
C  [libc.so.6+0xcfd0e]  clone+0x5e
Comments
It is possible that this was JDK-8268347.
15-06-2021
David's last comment: Upon discovering that the other bug converted to this, I was very eager to see this one happen because the test is so much smaller, but I could not get it to reproduce for me, either on OSX or on Linux, so I have gotten nowhere yet with this one.
02-03-2015
ILW=Bad behaviour in generated locking code, one test so far, none so far = HLH=P2 + nightly = P1
30-01-2015
JDK-8066576 looks very much like incorrect code at this point, but I don't know which incorrect code (yet). JNI occurs there also, however one crucial factor that must be present is lock elimination (disable the optimization, the problem goes away). The pattern I see there is that when the method in question is compiled and locks are eliminated, shortly afterwards the "recursion count" on certain locks (in certain manifestations of the bug) starts climbing into the sky -- and there is a debugging print in the lock code that activates when it goes up past a threshold and prints the count, so it is clear that this is what is really happening. This suggests that it might not be JNI and it also appears not to be deoptimization, both because I cannot see any in the relevant code, and because it goes up and up and up (4 digit hex numbers up and up -- far more than the number of deopts observed). I would hope to at least have figured out what the incorrect generated code path is sometime tomorrow.
29-01-2015
David, may be it is similar problem to what you are working on for JDK-8066576.
29-01-2015
setLevelsOnExistingLoggers is a synchronized method. Did C2 generate incorrect code? I would suggest moving to compiler team for analysis.
29-01-2015