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.

Sign up for GitHub

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

Jump to bottom

Ambiguous StackOverflow Exceptions: JRuby or Programmer Bug? #4783

Closed
aryeh-looker opened this issue Sep 7, 2017 · 2 comments
Closed

Ambiguous StackOverflow Exceptions: JRuby or Programmer Bug? #4783

aryeh-looker opened this issue Sep 7, 2017 · 2 comments
Milestone
Invalid or Duplicate

Comments

@aryeh-looker
Copy link
Contributor

Environment

$ jruby -v
jruby 9.1.8.0 (2.3.1) 2017-03-06 90fc7ab Java HotSpot(TM) 64-Bit Server VM 25.121-b13 on 1.8.0_121-b13 +jit [darwin-x86_64]

$ uname -a
Darwin abhillman-macbook-pro.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64

JRUBY_OPTS=-J-XX:+UseG1GC -J-XX:MaxGCPauseMillis=1000 -J-XX:MaxMetaspaceSize=512m -J-XX:+HeapDumpOnOutOfMemoryError -J-XX:HeapDumpPath=/tmp/ -J-Xms512m -J-Xmx2048m -J-Dapple.awt.UIElement=true -J-Djava.awt.headless=true -Xcli.encoding.external=UTF-8

Expected Behavior

It's not clear to me whether these traces are indicative of programmer error or a JRuby bug; if the traces are due to programmer error, it would be ideal to have a useful stack trace that mentions Ruby code.

Actual Behavior

Long stacktraces that only mention JRuby internals. An example trace (redacted because it's so long; full captured trace: https://gist.github.com/aryeh-looker/0288adbbafb8c40b24ce18a55748d6b4) — I get a lot of these in my application, but have been unable to consistently reproduce the problem:

Java::JavaLang::StackOverflowError: null
  from CompiledIRMethod.java:90:in `call'
  from MixedModeIRMethod.java:128:in `call'
  from CachingCallSite.java:139:in `callBlock'
  from CachingCallSite.java:145:in `call'
  from CompiledIRBlockBody.java:156:in `yieldDirect'
  from IRBlockBody.java:76:in `yieldSpecific'
  from Block.java:136:in `yieldSpecific'
  from IRRuntimeHelpers.java:450:in `yieldSpecific'
  from YieldSite.java:114:in `yieldSpecific'
  from CompiledIRMethod.java:90:in `call'
  from MixedModeIRMethod.java:128:in `call'
  from CachingCallSite.java:139:in `callBlock'
  from CachingCallSite.java:145:in `call'
  from CompiledIRBlockBody.java:156:in `yieldDirect'
  from IRBlockBody.java:76:in `yieldSpecific'
  from Block.java:136:in `yieldSpecific'
  from IRRuntimeHelpers.java:450:in `yieldSpecific'
  from YieldSite.java:114:in `yieldSpecific'
  from CompiledIRMethod.java:90:in `call'
  from MixedModeIRMethod.java:128:in `call'
  from CachingCallSite.java:139:in `callBlock'
  from CachingCallSite.java:145:in `call'
  from CompiledIRBlockBody.java:156:in `yieldDirect'
  from IRBlockBody.java:76:in `yieldSpecific'
@aryeh-looker aryeh-looker changed the title Ambiguous StackOverflow Exceptions: Programmer or JRuby Bug? Ambiguous StackOverflow Exceptions: JRuby or Programmer Bug? Sep 7, 2017
@headius
Copy link
Member

headius commented Sep 7, 2017

They could be a problem in the Ruby code you're running or they could be a problem in JRuby. A quick glance at your trace makes me think it's probably a JRuby bug.

CompilerIRBlockBody's next target should be the jitted version of that block, which would show up with a Ruby line number. Instead, it goes straight to another call site that calls the same method with the same block and it starts over again.

I see also you are running JRuby 9.1.8, which is several months old. There's a very good chance this has been fixed in more recent JRuby versions. Could you try updating and see if the problem goes away before we dig deeper?

@headius headius added this to the JRuby 9.2.0.0 milestone Sep 7, 2017
@headius
Copy link
Member

headius commented May 16, 2018

There's really no bug here.

If a stack overflow happens, we may rewrite it as a Ruby exception...but in both cases we consider it a fatal, unrecoverable error. We also are not generally in the habit of rewriting every Java exception that passes through Ruby, so you may see Java internals in this case.

@headius headius closed this as completed May 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Invalid or Duplicate
Development

No branches or pull requests
2 participants
@headius @aryeh-looker