JVM crash in ShenandoahInitMarkRootsClosure

[Roman Kennke]

It's hard to say. Does it happen without -XX:+UseStringDeduplication ? 
JDK-8221278 is only relevant with string deduplication explicitely 
turned on.

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