SIGSEGV in GraalVM 0.31

Sun Feb 18 21:49:19 UTC 2018

I wish I could provide the hs_err file, but as far as I can tell it's
not being generated. I checked all the normal places and I tried
specifying a path with XX:ErrorFile and no files ever appeared after the
crash. Is there some way to help it generate the file or make sure it
doesn't decide not to write the file?

My command line is below in case it has any issues. The most notable
part is that I use -XX:-UseJVMCIClassLoader since my language currently
uses a non-polyglot launcher. But I cannot see how that would be causing
this kind of problem.

-Dgraal.GraalCompileOnly=orc.run.*.* (and similar) seems to work around
the problem (I'm still running tests to make sure). From what I can tell
this causes everything else to be compiled to C1 at best instead of
being compiled with the HotSpot C2 compiler. Is that correct? (Just so I
can estimate the effect on performance.)

Thanks a lot for your quick weekend response.

-Arthur

graalvm-0.31/jre/bin/java -XX:-UseJVMCIClassLoader -XX:+UseJVMCICompiler
-XX:JVMCIThreads=1 -Dorc.numerics.preferLP=true -Xmx6000m
-Xbootclasspath:graalvm-0.31/jre/lib/resources.jar:graalvm-0.31/jre/lib/rt.jar:graalvm-0.31/jre/lib/jsse.jar:graalvm-0.31/jre/lib/jce.jar:graalvm-0.31/jre/lib/charsets.jar:graalvm-0.31/jre/lib/jfr.jar:graalvm-0.31/jre/lib/jvmci-services.jar:graalvm-0.31/jre/lib/boot/graaljs-scriptengine.jar:graalvm-0.31/jre/lib/boot/graal-sdk.jar:graalvm-0.31/jre/lib/boot/graal-sdk.src.zip:graalvm-0.31/jre/lib/jvmci/graal.jar:graalvm-0.31/jre/lib/truffle/truffle-api.jar:/home/amp/LocalInstalls/eclipse/plugins/org.scala-lang.scala-library_2.12.3.v20170725-052526-VFINAL-6ac6da8.jar:/home/amp/LocalInstalls/eclipse/plugins/org.scala-lang.scala-reflect_2.12.3.v20170725-052526-VFINAL-6ac6da8.jar
-classpath $ORCCLASSPATH orc.Main $ORCARGS

(I removed the absolute path from graalvm-0.31 for clarity, but all the
paths are actually absolute.)

ORCCLASSPATH=/home/amp/shared/orc/OrcScala/lib/scala-parser-combinators_2.12-1.0.6.jar:/home/amp/shared/orc/OrcScala/lib/scala-xml_2.12-1.0.6.jar:/home/amp/shared/orc/OrcTests/tools/junit-4.5.jar:/home/amp/shared/orc/OrcScala/lib/swivel_2.12-0.0.2.jar:/home/amp/shared/orc/OrcScala/build/classes:/home/amp/shared/orc/OrcSites/lib/axis-1.4.jar:/home/amp/shared/orc/OrcSites/lib/axis-jaxrpc-1.4.jar:/home/amp/shared/orc/OrcSites/lib/htmlparser.jar:/home/amp/shared/orc/OrcSites/lib/javax.mail-1.5.5.jar:/home/amp/shared/orc/OrcSites/lib/mimepull-1.9.6.jar:/home/amp/shared/orc/OrcSites/lib/smack.jar:/home/amp/shared/orc/OrcSites/lib/smackx.jar:/home/amp/shared/orc/OrcSites/lib/wsdl4j-1.6.3.jar:/home/amp/shared/orc/OrcSites/lib/jettison-1.3.7.jar:/home/amp/shared/orc/OrcSites/lib/oauth-20100527.jar:/home/amp/shared/orc/OrcSites/lib/oauth-consumer-20100527.jar:/home/amp/shared/orc/OrcSites/lib/oauth-httpclient3-20090617.jar:/home/amp/shared/orc/OrcSites/lib/oauth-provider-20100527.jar:/home/amp/shared/orc/OrcSites/lib/joda-time-1.5.2.jar:/home/amp/shared/orc/OrcSites/lib/ecj-4.5.2.jar:/home/amp/shared/orc/OrcSites/lib/commons-httpclient-3.1.jar:/home/amp/shared/orc/OrcSites/lib/commons-codec-1.3.jar:/home/amp/shared/orc/OrcSites/lib/commons-discovery-0.5.jar:/home/amp/shared/orc/OrcSites/lib/commons-logging-1.2.jar:/home/amp/shared/orc/OrcSites/lib/twitter4j-core-4.0.4.jar:/home/amp/shared/orc/OrcSites/lib/twitter4j-stream-4.0.4.jar:/home/amp/shared/orc/OrcSites/lib/jetty-all-9.3.11.v20160721-uber.jar:/home/amp/shared/orc/OrcSites/build/classes:/home/amp/shared/orc/OrcTests/build:/home/amp/shared/orc/PorcE/build/classes

ORCARGS=--backend porc -O 3 -I
/home/amp/shared/orc/OrcTests/src/orc/lib/includes
/home/amp/shared/orc/OrcTests/test_data/performance/black-scholes/black-scholes-scala-compute-partitioned-seq.orc

On 02/18/2018 03:08 PM, Doug Simon wrote:
> 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.)
>>