JRuby is able to cause a SIGSEGV in OpenJDK 7.x #4365

JasonLunn opened this Issue Dec 6, 2016 · 8 comments


None yet

3 participants

JasonLunn commented Dec 6, 2016 edited



Observed in two environments:

JRE version: OpenJDK Runtime Environment (7.0_101) (build 1.7.0_101-b00)
Java VM: OpenJDK 64-Bit Server VM (24.95-b01 mixed mode linux-amd64 compressed oops)
Derivative: IcedTea 2.6.6
Distribution: Ubuntu 12.04 LTS, package 7u101-2.6.6-0ubuntu0.12.04.1
Problematic frame:
V  [libjvm.so+0x4752fc]

Most frequent - running tests on our own TeamCity agents


JRE version: Java(TM) SE Runtime Environment (7.0_76-b13) (build 1.7.0_76-b13)
Java VM: Java HotSpot(TM) 64-Bit Server VM (24.76-b04 mixed mode linux-amd64 compressed oops)
Problematic frame:
V  [libjvm.so+0x7d23fd]  methodOopDesc::result_type() const+0xd

Less frequent - running tests for a different project on Travis

Expected Behavior

  • JVM doesn't crash hard, ever

Actual Behavior

headius commented Dec 11, 2016

Definitely looks like a JVM issue unfortunately. We might be able to mitigate it. This is latest Java 7 yes? And you can't use 8?


@headius - it is at least two different point releases of JDK7, both of which appear to be the latest for the distribution of the OS on which they're running. These are JVM's that have been happily running JRuby 1.7.x for some time with no such crash, so while I admit that if the JVM is crashing that's got to be a Java issue, it does seem that JRuby 9K knows how to excite that failure mode in a way that 1.7.x never did.

I have more log files like the one attached above if they would be helpful. Also, I've submitted a ticket for IcedTea here

headius commented Dec 12, 2016

Ok, had a chance to look at your crash log. It is crashing in the GC thread, so it's looking more like a JVM bug. You might try running with a different GC (it's using CMS, you could try parallel or G1 perhaps). I see there are some Ruby threads running, but it's pretty hard to know how closely they are related to the GC crash.

headius commented Dec 12, 2016

@bbrowning Any thoughts on this? According to the IcedTea issue, this is happening sporadically while running Torquebox tests.


To be clear, the crash log above is not from my branch of torquebox (because if there is a way to get arbitrary crash log files out of Travis when it fails then I don't know it). The crash log is from a different code base entirely - the common thread between them is that in both code bases I was trying to transition to


More samples from our TeamCity CI server running tests for an in-house application.


enebo commented Dec 12, 2016

2 of those 3 crash were within safepoints. I would have expected more all or nothing in that regard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment