@headius this seems safe to post: https://gist.github.com/digitalextremist/6e79ecc443d7d1632e3e

Be advised @tarcieri / @halorgium, I do not believe Celluloid is not stable on jRuby 9000 yet and I'm trying to figure out why. I've also gotten segfaults at start up before anything really happens in a server instance, which I'll post later.

/cc: @atambo, @enebo

Here was another piece of output I got right at start up one time. This time I had an actual core dump too, but it's stupid large. Too large for a gist.... over 3 gigs!

https://gist.github.com/digitalextremist/7f3c30f0dd3b6ef189dd

Once there's some semi-vague verdict even on what's up, I'll go back to testing 9000, otherwise I downgraded for a while. Hope something in those messes help?

I think 0aef21d will fix your problem. This was a known issue and we meant to figure out a way to disable it before pre, but forgot about it.

To clarify, this is a JVM bug that @chrisseaton first ran into a few months back and introduced a workaround, but it still crashes the JVM in some scenarios. AFAIK, @headius has brought this up with the JVM team, but since this piece of code is going to be disabled, we may not trigger the JVM bug in that scenario.

I'm impressed that this crystal-ball-territory mess drew any response at all, much less a possible line of code. Wish I could reliably trigger the crash. When that commit gets into -head please ping me and I'll re-up & resume trying to crash it. The issue sounds inter-lingual so I'll just get popcorn and watch it resolve itself. Feel free to close this once the commit is merged and pushed into the bloodstream.

That commit is merged (since I am a core committer) and is on the master repo. So, pull the latest version of master and get some popcorn.

Sweet @subbuss! Thanks!

jruby 9.0.0.0-SNAPSHOT (2.2.0p0) 2015-01-24 0aef21d Java HotSpot(TM) 64-Bit Server VM 25.25-b02 on 1.8.0_25-b17 +jit [linux-amd64]

@subbuss I've core dumped again with the new build of jruby:

• https://gist.github.com/edad37c1a5ab685ea399

Is that the same fault occurring? Are you still thinking it's the issue you first thought?

Another only a few minutes later: https://gist.github.com/abb4f94d30926661fe72

Switching back to 1.7.* for now until I get further instructions.

Hmm .. we'll see what our luck is in getting the JVM address this. In any case, we might try to play around some more with the interpreter loop to make the JVM not crash. To be continued ...

@headius asked if I was using InvokeDynamic and I am, if that matters. Has it degraded any since 1.17.18? I'm still experiencing #1658 also, if that helps at all. Neither issue is reproducible for me, and I'm not at all sure they are connected or even related.

Hi! I'm seeing what I think is the same JVM crash in a similar heavy MH/invokedynamic application (not JRuby). Do you have a JVM bug report @headius?

@lexs Can you post your crash?

This still appears to be a JVM bug, and I can now file such a bug, but without a way to reproduce it they generally just close them. So what we really need here is some way to reproduce this reliably.

Long defunct, please refile if this issue exists on a supported version of JRuby.