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

Stack overflow in unresolvedSuper logic from jitted code #4272

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

Comments

Projects
None yet
1 participant
@headius
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 in f2f6c54 Nov 9, 2016

@headius headius added this to the JRuby 9.1.6.0 milestone Nov 9, 2016

@headius headius added the regression label Nov 9, 2016

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Nov 9, 2016

Member

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.

Member

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