Truncated stacks

[Doerr, Martin]

Hi David,

> 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).

Best regards,
Martin


-----Original Message-----
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

Hi Martin,

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.

Thanks,
David

> 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
>