StackOverflowError when calling try on OpenStruct objects on JRuby 9.3.3.0

[rsim]

Environment Information

Provide at least:

• JRuby version (jruby -v) and command line (flags, JRUBY_OPTS, etc)
  jruby 9.3.3.0 (2.6.8) 2022-01-19 b26de1f5c5 OpenJDK 64-Bit Server VM 25.312-b07 on 1.8.0_312-b07 [darwin-aarch64]

• Operating system and platform (e.g. uname -a)
  Darwin 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000 arm64

Expected Behavior

We identified that in our Rails application try method on OpenStruct objects was raising StackOverflowError. I created a simple test case to reproduce it:

class Object
  def try(*a, &b)
    try!(*a, &b) if a.empty? || respond_to?(a.first)
  end

  def try!(*a, &b)
    if a.empty? && block_given?
      if b.arity == 0
        instance_eval(&b)
      else
        yield self
      end
    else
      public_send(*a, &b)
    end
  end
end

require "ostruct"
a = OpenStruct.new(a: "a")
begin
  puts a.try(:a)
rescue Exception => e
  puts e.class.name, e.message, e.backtrace
end

When using JRuby 9.2.20.1 and 9.3.2.0 this works as expected and puts "a".

Actual Behavior

When using JRuby 9.3.3.0 StackOverflowError is raised:

Java::JavaLang::StackOverflowError

org.jruby.RubyModule.cacheHit(RubyModule.java:1668)
org.jruby.RubyModule.searchWithCache(RubyModule.java:1560)
org.jruby.RubyModule.searchWithCacheAndRefinements(RubyModule.java:1566)
org.jruby.RubyModule.searchWithRefinements(RubyModule.java:1547)
org.jruby.RubyModule.respondsToMethod(RubyModule.java:2282)
org.jruby.RubyBasicObject.respond_to_p(RubyBasicObject.java:2079)
org.jruby.RubyKernel.respond_to_p(RubyKernel.java:2066)
org.jruby.RubyKernel$INVOKER$s$respond_to_p.call(RubyKernel$INVOKER$s$respond_to_p.gen)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:173)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:316)
org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:160)
org.jruby.internal.runtime.methods.InterpretedIRMethod.INTERPRET_METHOD(InterpretedIRMethod.java:127)
org.jruby.internal.runtime.methods.InterpretedIRMethod.call(InterpretedIRMethod.java:109)
org.jruby.internal.runtime.methods.AliasMethod.call(AliasMethod.java:125)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:85)
org.jruby.ir.instructions.CallBase.interpret(CallBase.java:549)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:361)
org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:160)
org.jruby.internal.runtime.methods.InterpretedIRMethod.INTERPRET_METHOD(InterpretedIRMethod.java:127)
org.jruby.internal.runtime.methods.InterpretedIRMethod.call(InterpretedIRMethod.java:109)
org.jruby.internal.runtime.methods.AliasMethod.call(AliasMethod.java:125)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:85)
org.jruby.ir.instructions.CallBase.interpret(CallBase.java:549)
...

Tried this on M1 MacBoook both with arm64 Java as well as with x64 Java and tried both Java 8 and 11. In all cases, StackOverflowError was raised.

As I cannot reproduce this problem with JRuby 9.3.2.0 then it seems that this is a recent change in the latest version which is causing this.

[rsim]

As a temporary workaround, I created a patch to avoid this exception

OpenStruct.class_eval do
  alias_method :try, :public_send
end

[headius]

This also fails in Ruby 3.1 so I think this is either a flaw in your code (unlikely since it worked before) or a bug in how ostruct is aliasing these methods:

$ rvm ruby-3.1 do ruby blah.rb
SystemStackError
stack level too deep
blah.rb:3:in `try'
blah.rb:3:in `try'
blah.rb:3:in `try'
blah.rb:3:in `try'
blah.rb:3:in `try'
blah.rb:3:in `try'
blah.rb:3:in `try'

This issue should probably be moved to https://github.com/ruby/ostruct.

cc @marcandre

[marcandre]

Interesting.

If you require ostruct first, bug disappears.

Confirmed as a defect; ostruct should not override already defined methods (like try! here).

[headius]

@marcandre @rsim I will close this as invalid since it is an issue in ostruct.