SIGSEGV in GraalVM 0.31

[Doug Simon]

Hi Arthur,

To begin with, thanks for another useful and well submitted bug report.

> On 18 Feb 2018, at 21:21, Arthur Peters <amp at cs.utexas.edu> wrote:
> 
> I have run into a Graal VM crash (SIGSEGV) when executing compiled Scala
> code. The problem occurs before Truffle initializes and only seems to
> happen when UseJVMCICompiler is turned on. Currently reproducing this
> crash requires running the entire Orc compiler
> (https://github.com/orc-lang/orc) and the crash is non-deterministic
> (occasionally the program runs much longer before crashing). Adding
> -XX:JVMCIThreads=1 works around the crash. I'm pretty sure it's a
> concurrency race somewhere in Graal that our Scala parser code can trigger.
> 
> I have a couple of questions:
> 
> 1. How can I determine what part of the Orc code is causing the crash?
>    I want to be able to create a minimal test case for you all.

The most useful piece of information you can provide is the hs_err file that HotSpot (almost always) produces on a crash. If we're lucky, it will show a stack trace for the crashing thread. If not, we at least see the methods most recently JIT compiled.

> 2. For future issues like this, is it possible to disable the JVMCI
>    last-tier compiler for some packages (or jars) but not others? That
>    would make it easy to enable Graal on the packages that need it and
>    disable it for others.

There is the -Dgraal.GraalCompileOnly option which takes a method filter in the same format[1] as the -Dgraal.MethodFilter option. For example, -Dgraal.GraalCompileOnly=orc.run.extensions.*.*,orc.run.porce.call.*.* will restrict Graal compilation to all packages starting with "orc.run.extensions." and "orc.run.porce.call.". Note that this option does not force a method to be compiled by Graal (or compiled at all). It is only applied to a method the VM has already selected for compilation by Graal.

> 
> Below is a trimmed version of one of the core dumps (well information I
> extracted from it). A number of compete dumps are at:
> https://gist.github.com/arthurp/9e725864d1c211e4238677cc787f6ba4

Thanks for the copious info! However, the best starting point would be a hs_err file - I'm assuming one is produced by the crash?

-Doug

[1] https://raw.githubusercontent.com/oracle/graal/d242032a2fa1757b4f14df3e8b42d3354f7da03c/compiler/src/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/MethodFilterHelp.txt

> GDB bt output:
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> 
> Thread 1 (Thread 0x7f67d232d700 (LWP 29881)):
> #0  0x00007f67d106f8ca in SharedRuntime::get_poll_stub(unsigned char*)
> () from /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #1  0x00007f67d0fcd8d9 in JVM_handle_linux_signal () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #2  0x00007f67d0fc1b48 in signalHandler(int, siginfo*, void*) () from
> /home/amp/shared/graalvm/graalvm-0.31/jre/lib/amd64/server/libjvm.so
> #3  <signal handler called>
> #4 0x00007f67b8087a1b in ?? ()
> [...]
> 
> jstack output:
> 
> Thread 29881: (state = IN_JAVA)
> 
> (this is not cut, the crashed thread always shows IN_JAVA and no stack.)
>