Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mysterious core dump / segfault with 9.0.0.0-pre. #2506

Closed
digitalextremist opened this issue Jan 23, 2015 · 14 comments
Closed

Mysterious core dump / segfault with 9.0.0.0-pre. #2506

digitalextremist opened this issue Jan 23, 2015 · 14 comments

Comments

@digitalextremist
Copy link
Contributor

@digitalextremist digitalextremist commented Jan 23, 2015

Not sure where to even begin describing this issue. I have 2.8+ megabytes of error output and am afraid to post it all here in case it has something compromising in it. Let me know where to privately post a secret gist and the trainwreck is all yours free of charge.

The fatal error completely took out all fault-tolerance for my otherwise impossible to kill process, down to crashing the Java VM itself. In other words, major show-stopper.

Using: jruby 9.0.0.0.pre1 (2.2.0p0) 2015-01-22 e038fe1 Java HotSpot(TM) 64-Bit Server VM 25.25-b02 on 1.8.0_25-b17 +jit [linux-amd64]

I am 90% sure this is related to extremely heavy use of Celluloid but am not certain.

@digitalextremist
Copy link
Contributor Author

@digitalextremist digitalextremist commented Jan 24, 2015

@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

Loading

@digitalextremist
Copy link
Contributor Author

@digitalextremist digitalextremist commented Jan 24, 2015

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?

Loading

@subbuss
Copy link
Contributor

@subbuss subbuss commented Jan 24, 2015

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.

Loading

@subbuss
Copy link
Contributor

@subbuss subbuss commented Jan 24, 2015

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.

Loading

@digitalextremist
Copy link
Contributor Author

@digitalextremist digitalextremist commented Jan 24, 2015

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.

Loading

@subbuss
Copy link
Contributor

@subbuss subbuss commented Jan 24, 2015

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.

Loading

@subbuss subbuss added this to the 9.0.0.0.pre2 milestone Jan 24, 2015
@digitalextremist
Copy link
Contributor Author

@digitalextremist digitalextremist commented Jan 24, 2015

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]

Loading

@digitalextremist
Copy link
Contributor Author

@digitalextremist digitalextremist commented Jan 24, 2015

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

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

Loading

@digitalextremist
Copy link
Contributor Author

@digitalextremist digitalextremist commented Jan 24, 2015

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

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

Loading

@subbuss
Copy link
Contributor

@subbuss subbuss commented Jan 26, 2015

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 ...

Loading

@digitalextremist
Copy link
Contributor Author

@digitalextremist digitalextremist commented Jan 26, 2015

@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.

Loading

@headius headius added this to the 9.0.0.0.rc1 milestone Apr 17, 2015
@headius headius removed this from the 9.0.0.0.pre2 milestone Apr 17, 2015
@lexs
Copy link

@lexs lexs commented Apr 20, 2015

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?

Loading

@enebo enebo removed this from the JRuby 9.0.0.0.rc1 milestone Jun 10, 2015
@enebo enebo added this to the JRuby 9.0.0.0.rc2 milestone Jun 10, 2015
@enebo enebo added this to the JRuby 9.0.0.0.rc2 milestone Jun 10, 2015
@enebo enebo removed this from the JRuby 9.0.0.0.rc1 milestone Jun 10, 2015
@headius
Copy link
Member

@headius headius commented Jul 2, 2015

@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.

Loading

@enebo enebo removed this from the JRuby 9.0.0.0.rc2 milestone Jul 9, 2015
@enebo enebo added this to the JRuby 9.0.0.0 milestone Jul 9, 2015
@enebo enebo added this to the JRuby 9.0.0.0 milestone Jul 9, 2015
@enebo enebo removed this from the JRuby 9.0.0.0.rc2 milestone Jul 9, 2015
@enebo enebo removed this from the JRuby 9.0.0.0 milestone Jul 14, 2015
@enebo enebo removed this from the JRuby 9.0.0.0 milestone Jul 14, 2015
@headius
Copy link
Member

@headius headius commented Jul 8, 2020

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

Loading

@headius headius closed this Jul 8, 2020
@headius headius added this to the Invalid or Duplicate milestone Jul 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants