Truncated stacks

[David Holmes]

I've been unable to reproduce this in a simple test case unfortunately.

David

On 20/12/2018 11:30 pm, Doerr, Martin wrote:
> 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
>>