Stack overflow in unresolvedSuper logic from jitted code #4272

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

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 added a commit that closed this issue Nov 9, 2016
@headius headius Reinstate WrapperMethod for visibility changes. Fixes #4272.
This was introduced via a fix for #3869, to update impl class so
that transplanted methods would super correctly. However, this
logic - which does not want a new impl class - got caught up. The
fix here reverts to using WrapperMethod for now, until we start
managing visibilty more like MRI or come up with a better fix.
f2f6c54
@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
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