martin.doerr at sap.com
Thu Dec 20 13:30:36 UTC 2018
> That's interesting, I wonder why? And can we fix that?
The "unlock" is implemented as a leaf call (no safepoint). So the last Java frame is not strictly required.
In contrast to this, "lock" uses an OptoRuntime stub which does set last Java frame.
I general, it would be possible to do this for the "unlock", too, but that would need C2 adaptations.
Anyway, this may not be necessary to get a native stack trace. I rather guess that something confuses the stack walk on x86 (or no backlink available).
From: David Holmes <david.holmes at oracle.com>
Sent: Donnerstag, 20. Dezember 2018 13:22
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net
Subject: Re: Truncated stacks
On 20/12/2018 9:57 pm, Doerr, Martin wrote:
> Hi David,
> is only this unlock call affected?
No - the first example is unlock, the second is lock.
> 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.
That's interesting, I wonder why? And can we fix that?
> 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?
Both bugs were reported on x86 and that's all I've looked at so far.
I may have to whip up a simple test to check the behaviour more broadly.
> Best regards,
> -----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
> 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
> C 0x0000004187bfcf5e
> Thread 1005 (Thread 0x7f30bb1ff700 (LWP 7275)):
> #0 0x00007f30f950d705 in pthread_cond_wait@@GLIBC_2.3.2 () from
> #1 0x00007f30f7b2d033 in os::PlatformEvent::park() () from
> #2 0x00007f30f7af7d2d in ObjectMonitor::EnterI(Thread*) () from
> #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
> #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.
More information about the hotspot-dev