JDK-8354523 : runtime/Monitor/SyncOnValueBasedClassTest.java triggers SIGSEGV
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64,aarch64
  • Submitted: 2025-04-14
  • Updated: 2025-04-21
  • Resolved: 2025-04-21
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 25
25 masterFixed
Related Reports
Causes :  
JDK-8339114 - DaCapo xalan performance with -XX:+UseObjectMonitorTable
Causes :  
JDK-8353588 - [REDO] DaCapo xalan performance with -XX:+UseObjectMonitorTable
Description
Test runtime/Monitor/SyncOnValueBasedClassTest.java recently triggered a SIGSEGV.

#  SIGSEGV (0xb) at pc=0x00007f3e69094755, pid=61220, tid=61293
# V  [libjvm.so+0xc35755]  LightweightSynchronizer::inflate_and_enter(oopDesc*, BasicLock*, ObjectSynchronizer::InflateCause, JavaThread*, JavaThread*)+0x85

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc35755]  LightweightSynchronizer::inflate_and_enter(oopDesc*, BasicLock*, ObjectSynchronizer::InflateCause, JavaThread*, JavaThread*)+0x85  (atomic_linux_x86.hpp:48)
V  [libjvm.so+0xc381fc]  LightweightSynchronizer::enter(Handle, BasicLock*, JavaThread*)+0x64c  (lightweightSynchronizer.cpp:693)
V  [libjvm.so+0xe93527]  SharedRuntime::monitor_enter_helper(oopDesc*, BasicLock*, JavaThread*)+0xc7  (synchronizer.inline.hpp:49)
V  [libjvm.so+0x5c995b]  Runtime1::monitorenter(JavaThread*, oopDesc*, BasicObjectLock*)+0x2b  (c1_Runtime1.cpp:768)
v  ~RuntimeStub::C1 Runtime monitorenter_nofpu_blob 0x00007f3e57ee27e3
J 462 c1 SyncOnValueBasedClassTest$LogTest.run()V (40 bytes) @ 0x00007f3e57f92a00 [0x00007f3e57f92880+0x0000000000000180]
J 461 c1 java.lang.Thread.run()V java.base@25-internal (23 bytes) @ 0x00007f3e57f9261c [0x00007f3e57f92580+0x000000000000009c]
v  ~StubRoutines::call_stub 0x00007f3e57dd7ca6
V  [libjvm.so+0x9a98b0]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x2b0  (javaCalls.cpp:415)
V  [libjvm.so+0x9ab21f]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x1df  (javaCalls.cpp:323)
V  [libjvm.so+0xa847dc]  thread_entry(JavaThread*, JavaThread*)+0x8c  (jvm.cpp:2748)
V  [libjvm.so+0x9c0468]  JavaThread::thread_main_inner() [clone .part.0]+0xb8  (javaThread.cpp:772)
V  [libjvm.so+0xfbb20f]  Thread::call_run()+0x9f  (thread.cpp:231)
V  [libjvm.so+0xdc3e66]  thread_native_entry(Thread*)+0xd6  (os_linux.cpp:877)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::C1 Runtime monitorenter_nofpu_blob 0x00007f3e57ee27e3
J 462 c1 SyncOnValueBasedClassTest$LogTest.run()V (40 bytes) @ 0x00007f3e57f92a00 [0x00007f3e57f92880+0x0000000000000180]
J 461 c1 java.lang.Thread.run()V java.base@25-internal (23 bytes) @ 0x00007f3e57f9261c [0x00007f3e57f92580+0x000000000000009c]
v  ~StubRoutines::call_stub 0x00007f3e57dd7ca6

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x00007f3e69e55834

Machine info is 
Host: Intel(R) Xeon(R) Platinum 8260M CPU @ 2.40GHz, 8 cores, 23G, SUSE Linux Enterprise Server 15 SP3
Time: Thu Apr 10 19:41:16 2025 CEST elapsed time: 0.334267 seconds (0d 0h 0m 0s)

Maybe important - UseCompactObjectHeaders  was set on this build to test compat object headers.
Comments
Changeset: ecb54a05 Branch: master Author: Roman Kennke <rkennke@openjdk.org> Date: 2025-04-21 17:43:09 +0000 URL: https://git.openjdk.org/jdk/commit/ecb54a05c6774e1a93d76b1181bda734129b6ace
21-04-2025
I added your PR to our build/test queue, probably it will fix those sporadic failures/crashes of SyncOnValueBasedClassTest.java .
16-04-2025
We saw another occurrence last night, also Linux x86_64 , this time fastdebug (last time opt). So it is 'a little bit' reproducable. Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x166e477] ObjectMonitor::try_lock(JavaThread*)+0x17 (atomic.hpp:553) V [libjvm.so+0x166e6bb] ObjectMonitor::try_enter(JavaThread*, bool)+0x1b (objectMonitor.cpp:438) V [libjvm.so+0x14001a1] LightweightSynchronizer::inflate_and_enter(oop, BasicLock*, ObjectSynchronizer::InflateCause, JavaThread*, JavaThread*)+0x121 (lightweightSynchronizer.cpp:1042) V [libjvm.so+0x140140a] LightweightSynchronizer::enter(Handle, BasicLock*, JavaThread*)+0x33a (lightweightSynchronizer.cpp:706) V [libjvm.so+0x18574ad] SharedRuntime::monitor_enter_helper(oopDesc*, BasicLock*, JavaThread*)+0x38d (synchronizer.inline.hpp:49) V [libjvm.so+0x8df91d] Runtime1::monitorenter(JavaThread*, oopDesc*, BasicObjectLock*)+0x6d (c1_Runtime1.cpp:768) v ~RuntimeStub::C1 Runtime monitorenter_nofpu_blob 0x00007ff5a060ec6f J 462 c1 SyncOnValueBasedClassTest$LogTest.run()V (40 bytes) @ 0x00007ff5a085cbe5 [0x00007ff5a085ca00+0x00000000000001e5] J 461 c1 java.lang.Thread.run()V java.base@25-internal (23 bytes) @ 0x00007ff5a085c7fc [0x00007ff5a085c700+0x00000000000000fc] v ~StubRoutines::call_stub 0x00007ff5a05ded01 V [libjvm.so+0xfef9f3] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x503 (javaCalls.cpp:415) V [libjvm.so+0xff0083] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x303 (javaCalls.cpp:323) V [libjvm.so+0xff06ae] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0xae (javaCalls.cpp:185) V [libjvm.so+0x117dac7] thread_entry(JavaThread*, JavaThread*)+0xd7 (jvm.cpp:2748) V [libjvm.so+0x102b9df] JavaThread::thread_main_inner()+0x12f (javaThread.cpp:773) V [libjvm.so+0x1a19666] Thread::call_run()+0xb6 (thread.cpp:231) V [libjvm.so+0x16bd1b8] thread_native_entry(Thread*)+0x128 (os_linux.cpp:877) Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~RuntimeStub::C1 Runtime monitorenter_nofpu_blob 0x00007ff5a060ec6f J 462 c1 SyncOnValueBasedClassTest$LogTest.run()V (40 bytes) @ 0x00007ff5a085cbe5 [0x00007ff5a085ca00+0x00000000000001e5] J 461 c1 java.lang.Thread.run()V java.base@25-internal (23 bytes) @ 0x00007ff5a085c7fc [0x00007ff5a085c700+0x00000000000000fc] v ~StubRoutines::call_stub 0x00007ff5a05ded01 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000168
16-04-2025
Adding the original issue, too
15-04-2025
Is it reproducible on your side? I have an idea and if you can reproduce it, I could make a patch/PR for you to try.
15-04-2025
I've literally run this test in a loop for the past 16 hours, without crashing. Not sure how to reproduce it.
15-04-2025
I've added the hs_err crash log file.
15-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24660 Date: 2025-04-15 12:47:47 +0000
15-04-2025
I think I know what's going on. When DiagnoseSyncOnValueBasedClasses is != 0, then we can take the slow-path without having cleared the monitor cache in the BasicLock. This would later lead to a crash or other unexpected behaviour. This can happen with C1 or the interpreter, C2 has the DiagnoseSyncOnValueBasedClasses-block after clearing the cache, and the native-entry in sharedRuntime_x86_64.cpp does not have a DiagnoseSyncOnValueBasedClasses-block at all.
15-04-2025
> Is it reproducible on your side? So far we had it only once in our central test runs so it is not so easily reproducible. Have to add that we run in those tests the whole jtreg tier , with some concurrency ; this might influence the occurrence too.
15-04-2025
Do you have the hs_err file for this crash?
14-04-2025