david.holmes at oracle.com
Fri Dec 21 07:19:42 UTC 2018
I've been unable to reproduce this in a simple test case unfortunately.
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,
> -----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.
>> 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