Truncated stacks

Doerr, Martin martin.doerr at sap.com
Thu Dec 20 11:57:44 UTC 2018


Hi David,

is only this unlock call affected?

I think regular Java stack walking doesn't work by design. C2 calls SharedRuntime::complete_monitor_unlocking_C without setting last  Java frame (PhaseMacroExpand::expand_unlock_node). So the last Java frame based walking won't work.

Native stack walking may or may not work depending on platform and build options. On x86, you will probably need backlinks to find a frame which belongs to generated code below a C++ frame. Is only x86 affected?

Best regards,
Martin


-----Original Message-----
From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of David Holmes
Sent: Donnerstag, 20. Dezember 2018 06:38
To: hotspot-dev at openjdk.java.net
Subject: Truncated stacks

We've noticed a problem investigating bug reports involving monitor 
lock/unlock. It seems that the stacks for threads in hs_err reports, in 
jstack -mixed output and even in gdb are truncated very high up e.g.

Stack: [0x00000041adef0000,0x00000041adff0000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
V [jvm.dll+0xb49bd1] os::platform_print_native_stack+0xf1 
(os_windows_x86.cpp:369)
V [jvm.dll+0xd67860] VMError::report+0xe80 (vmerror.cpp:698)
V [jvm.dll+0xd690b4] VMError::report_and_die+0x854 (vmerror.cpp:1463)
V [jvm.dll+0xd69774] VMError::report_and_die+0x64 (vmerror.cpp:1287)
V [jvm.dll+0x57be7e] report_vm_error+0x7e (debug.cpp:232)
V [jvm.dll+0xb21db4] ObjectMonitor::exit+0xf4 (objectmonitor.cpp:1025)
V [jvm.dll+0xc0f08a] SharedRuntime::complete_monitor_unlocking_C+0x17a 
(sharedruntime.cpp:2062)
C 0x0000004187bfcf5e


or:

Thread 1005 (Thread 0x7f30bb1ff700 (LWP 7275)):
#0  0x00007f30f950d705 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x00007f30f7b2d033 in os::PlatformEvent::park() () from 
/scratch/fairoz/JAVA/jdk12/jdk-12-ea+24/lib/server/libjvm.so
#2  0x00007f30f7af7d2d in ObjectMonitor::EnterI(Thread*) () from 
/scratch/fairoz/JAVA/jdk12/jdk-12-ea+24/lib/server/libjvm.so
#3  0x00007f30f7af9a62 in ObjectMonitor::enter(Thread*) [clone .part.90] 
() from /scratch/fairoz/JAVA/jdk12/jdk-12-ea+24/lib/server/libjvm.so
#4  0x00007f30f7c9bcd2 in ObjectSynchronizer::fast_enter(Handle, 
BasicLock*, bool, Thread*) () from 
/scratch/fairoz/JAVA/jdk12/jdk-12-ea+24/lib/server/libjvm.so
#5  0x00007f30f7c02584 in 
SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, 
JavaThread*) ()
    from /scratch/fairoz/JAVA/jdk12/jdk-12-ea+24/lib/server/libjvm.so
#6  0x00007f30ddde2228 in ?? ()
#7  0x0000000638200fc8 in ?? ()
#8  0x00007f30e57e1330 in ?? ()
#9  0x00000001000003e8 in ?? ()
#10 0x0000000638200920 in ?? ()
#11 0x000000080113fa80 in ?? ()
#12 0x0000000638200fe8 in ?? ()
#13 0xc70405d300000000 in ?? ()
#14 0x0000000638200fd8 in ?? ()
#15 0x0000000801146328 in ?? ()
#16 0x00000006382014d8 in ?? ()
#17 0x0000000638202e98 in ?? ()
#18 0x0000000638202eb0 in ?? ()
#19 0xc704029b382317f8 in ?? ()
#20 0x0000000000000000 in ?? ()

Anyone have any ideas about what have broken things? I haven't had time 
to try and determine how long this has been occurring.

Thanks,
David


More information about the hotspot-dev mailing list