JVM crash in ShenandoahInitMarkRootsClosure

[Omar Kilani]

Hi Roman,

We also see:

---------------  T H R E A D  ---------------
Current thread (0x00007fa0ac192800):  GCTaskThread "Shenandoah GC
Threads#9" [stack: 0x00007fa08d1f6000,0x00007fa08d2f6000] [id=10523]

Stack: [0x00007fa08d1f6000,0x00007fa08d2f6000],
sp=0x00007fa08d2f4520,  free space=1017k

Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)

V  [libjvm.so+0xd6ccd8]  void
ShenandoahHeap::marked_object_iterate<ShenandoahObjectToOopClosure<ShenandoahUpdateHeapRefsClosure
(ShenandoahHeapRegion*,
ShenandoahObjectToOopClosure<ShenandoahUpdateHeapRefsClosure>*,
HeapWord*)+0x288
V  [libjvm.so+0xd6d54d]
ShenandoahUpdateHeapRefsTask<ShenandoahUpdateHeapRefsClosure>::do_work()+0xad
V  [libjvm.so+0xd6d70c]
ShenandoahUpdateHeapRefsTask<ShenandoahUpdateHeapRefsClosure>::work(unsigned
int)+0x5c
V  [libjvm.so+0xf565bd]  GangWorker::loop()+0x4d
V  [libjvm.so+0xec2b35]  Thread::call_run()+0x75
V  [libjvm.so+0xc000ce]  thread_native_entry(Thread*)+0xee

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
0x00007fa4af6422a0

--

In a different app. Is this the same bug, or a different thing?

Thanks!

Regards,
Omar

On Wed, Mar 27, 2019 at 11:39 AM Roman Kennke <rkennke at redhat.com> wrote:
>
> Hi Omar,
>
> yes, that seems very likely. The fix should appear in nightlies very soon.
>
> Thanks, Roman
>
>
> > Hi there,
> >
> > We're testing:
> >
> > OpenJDK 64-Bit Server VM
> > (12-testing+0-builds.shipilev.net-openjdk-jdk12-b140-20190320-jdk-1233)
> >
> > And had a crash in one of our applications:
> >
> > ---------------  T H R E A D  ---------------
> > Current thread (0x00007febe8156000):  GCTaskThread "Shenandoah GC
> > Threads#5" [stack: 0x00007febec68a000,0x00007febec78a000] [id=2927]
> > Stack: [0x00007febec68a000,0x00007febec78a000],
> > sp=0x00007febec788ae0,  free space=1018k
> >
> > Native frames: (J=compiled Java code, A=aot compiled Java code,
> > j=interpreted, Vv=VM code, C=native code)
> >
> > V  [libjvm.so+0xd24b2d]
> > ShenandoahInitMarkRootsClosure<(UpdateRefsMode)0,
> > (StringDedupMode)1>::do_oop(oopDesc**)+0x7d
> > V  [libjvm.so+0xd7c6c6]
> > ShenandoahStrDedupQueue::unlink_or_oops_do_impl(StringDedupUnlinkOrOopsDoClosure*,
> > unsigned long)+0x96
> > V  [libjvm.so+0xe09aa3]
> > StringDedupQueue::unlink_or_oops_do(StringDedupUnlinkOrOopsDoClosure*)+0x43
> > V  [libjvm.so+0xd7d3e8]
> > ShenandoahStringDedup::parallel_oops_do(OopClosure*, unsigned
> > int)+0x58
> > V  [libjvm.so+0xd7b4f1]
> > ShenandoahRootProcessor::process_vm_roots(OopClosure*, OopClosure*,
> > OopClosure*, unsigned int)+0x111
> > V  [libjvm.so+0xd7b87a]
> > ShenandoahRootProcessor::process_all_roots(OopClosure*, OopClosure*,
> > CLDClosure*, CodeBlobClosure*, ThreadClosure*, unsigned int)+0x7a
> > V  [libjvm.so+0xd19000]
> > ShenandoahInitMarkRootsTask<(UpdateRefsMode)0>::work(unsigned
> > int)+0x200
> > V  [libjvm.so+0xf565bd]  GangWorker::loop()+0x4d
> > V  [libjvm.so+0xec2b35]  Thread::call_run()+0x75
> > V  [libjvm.so+0xc000ce]  thread_native_entry(Thread*)+0xee
> >
> > siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr:
> > 0x0000000000000000
> >
> > --
> >
> > Is this fixed by:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8221278
> >
> > ? :)
> >
> > Thanks!
> >
> > Regards,
> > Omar
> >
>