shenandoah c2 compiler crash in jdk8

[Nick Evgeniev]

hi,

yes, replay is what I'm doing (i.e. all my previous posts are based on
-XX:+ReplayCompiles)... crash in prod is hard to reproduce

On Tue, 3 Nov 2020 at 06:42, Roland Westrelin <rwestrel at redhat.com> wrote:

>
> > also just in case there is original stack trace (from release build w/o
> > assertions):
> >
> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> > code)
> > V  [libjvm.so+0x4b6eae]  Compile::final_graph_reshaping()+0x1e
> > V  [libjvm.so+0x4b923e]  Compile::Optimize()+0xd8e
> > V  [libjvm.so+0x4bb217]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*,
> > int, bool, bool, bool)+0x11c7
> > V  [libjvm.so+0x40fd8c]  C2Compiler::compile_method(ciEnv*, ciMethod*,
> > int)+0x20c
> > V  [libjvm.so+0x4c2096]
> >  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd46
> > V  [libjvm.so+0x4c4977]  CompileBroker::compiler_thread_loop()+0x657
> > V  [libjvm.so+0xb22981]  JavaThread::thread_main_inner()+0xf1
> > V  [libjvm.so+0x9674a2]  java_start(Thread*)+0x132
> > C  [libpthread.so.0+0x7ea5]  start_thread+0xc5
>
> Thanks. I'm surprised the assert and the crash are related. The assert
> catches the IR graph growing too big. That in itself shouldn't cause a
> crash in the release build. I suppose the release build crash doesn't
> reproduce once the node limit is bumped? Maybe that hides the bug rather
> than work around it.
>
> One way to reproduce the issues is by using replay compilation. The VM
> should have dumped replay_pid files for the 2 crashes. Running:
>
> java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pidxxx.log
> -XX:+ReplayIgnoreInitErrors
>
> with the same classpath and compile time option as the actual runs is
> often all it takes to reproduce the crash. The VM needs to find every
> class that's mentioned in the replay file (it's a text file so you can
> look into it).
>
> If that works then and you were willing to share the class files I
> should be able to reproduce it as well.
>
> Roland.
>
>