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

Stack overflow in unresolvedSuper logic from jitted code #4272

Closed
headius opened this issue Nov 8, 2016 · 1 comment
Closed

Stack overflow in unresolvedSuper logic from jitted code #4272

headius opened this issue Nov 8, 2016 · 1 comment
Labels
regression
Milestone
JRuby 9.1.6.0

Comments

@headius
Copy link
Member

headius commented Nov 8, 2016

Environment

At least JRuby 9.1.5.0 and 9.1.6.0.

Attempting to run tests with -Xjit.threshold=0 for hexapdf.

Expected Behavior

When running with threshold=0, the tests should still run.

Actual Behavior

Instead, we get the following stack overflow:

/Users/headius/projects/jruby/lib/ruby/gems/shared/gems/rake-11.3.0/lib/rake/task.rb:197: warning: singleton on non-persistent Java type Java::JavaLang::StackOverflowError (http://wiki.jruby.org/Persistence)
rake aborted!
Java::JavaLang::StackOverflowError: 
Users.headius.projects.jruby.lib.ruby.gems.shared.gems.rake_minus_11_dot_3_dot_0.lib.rake.file_utils_ext.RUBY$method$ruby$0(/Users/headius/projects/jruby/lib/ruby/gems/shared/gems/rake-11.3.0/lib/rake/file_utils_ext.rb:34)
org.jruby.internal.runtime.methods.CompiledIRMethod.invokeExact(CompiledIRMethod.java:210)
org.jruby.internal.runtime.methods.CompiledIRMethod.call(CompiledIRMethod.java:88)
org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:93)
org.jruby.ir.runtime.IRRuntimeHelpers.unresolvedSuper(IRRuntimeHelpers.java:1014)
org.jruby.ir.runtime.IRRuntimeHelpers.unresolvedSuperSplatArgs(IRRuntimeHelpers.java:990)
Users.headius.projects.jruby.lib.ruby.gems.shared.gems.rake_minus_11_dot_3_dot_0.lib.rake.file_utils_ext.invokeSuper5:-unknown-super-target-(/Users/headius/projects/jruby/lib/ruby/gems/shared/gems/rake-11.3.0/lib/rake/file_utils_ext.rb:34)
Users.headius.projects.jruby.lib.ruby.gems.shared.gems.rake_minus_11_dot_3_dot_0.lib.rake.file_utils_ext.RUBY$method$ruby$0(/Users/headius/projects/jruby/lib/ruby/gems/shared/gems/rake-11.3.0/lib/rake/file_utils_ext.rb:34)
...

It appears that the calculation of what class to "super" up ends up with wrong results in the JIT. Specifically, in this case, Rake's FileUtilsExt module, which mixes in FileUtils and which is itself extended into other classes, ends up finding itself as its own superclass. I have been unable to reproduce the problem with a simple snippit; there's something different in the Rake class hierarchy that's triggering this.

To reproduce, just check out hexapdf and run jruby -Xjit.threshold=0 -S rake test.
@headius headius closed this as completed in f2f6c54 Nov 9, 2016
@headius headius added this to the JRuby 9.1.6.0 milestone Nov 9, 2016
@headius
Copy link
Member Author

headius commented Nov 9, 2016

For the record, this was introduced in 9b4e97b. The change there caused this stack overflow because it duplicated a method, stuffed it into a child class, changed its impl class to that child, and that caused it to super into itself repeatedly. This change reverts to WrapperMethod, which only serves to hold a method plus a new visibility in our method tables, and does not pass on implementationClass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
regression
Projects
None yet
Milestone
JRuby 9.1.6.0
Development

No branches or pull requests
1 participant
@headius