Calling super from a method in an included module can invoke the wrong superclass

[philr]

1. What command did you run?

I ran ruby rbx_strftime.rb, where rbx_strftime.rb is the following:

module Extension
  def strftime(format)    
    super('%Y')
  end
end

class ExtendedTime < Time
  include Extension
end

class ExtendedTime2 < Time
  include Extension
end

class TestClass
  def strftime(format)
    "TestClass: #{format}"
  end
end

class ExtendedTestClass < TestClass
  include Extension
end

puts ExtendedTime.new(2018).strftime('x')
puts ExtendedTime2.new(2018).strftime('x')
3.times { puts ExtendedTestClass.new.strftime('x') }

2. What behavior did you expect?

I expected the following output:

2018
2018
TestClass: %Y
TestClass: %Y
TestClass: %Y

3. What behavior did you get instead?

The third execution of puts ExtendedTestClass.new.strftime('x') resulted in a PrimitiveFailure exception being raised instead of the output of the last TestClass: %Y line (see https://gist.github.com/philr/b22784c46411a5b79dc53e57011f80f2#file-rbx_strftime_output-txt). The stack trace appears to indicate that the super call in Extension#strftime invoked Time#strftime instead of the expected TestClass#strftime.

4. What version of Rubinius?

3.93

Output of rbx -v:

rubinius 3.93 (2.3.1 75512369 2018-01-20 4.0.0) [x86_64-linux-gnu]

5. What version of operating system?

Ubuntu 17.04 (x86_64)

Output of uname -a:

Linux linuxdev 4.10.0-42-generic #46-Ubuntu SMP Mon Dec 4 14:38:01 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

6. What is your operating system distribution, if your operating system has more than one?

Ubuntu 17.04

7. How did you build your version of Rubinius?

• I used RVM.
• I used ruby-build.
• I used ruby-install.
• I built manually from a tarball.
• I built manually from a git clone.
• I installed a binary.

8. Does this issue involve proprietary code?

• Yes, this issue involves proprietary code that I cannot share.
• Yes, this issue involves proprietary code, but I am able to share it under certain conditions.
• No, this issue doesn't involve proprietary code.

9. Are you able to help us debug the issue?

• Yes, I'm able to help debug, including running commands under lldb.
• No, I'm not able help debug or I don't have time to help.

[brixen]

@philr this is a pretty bizarre bug with a couple different aspects. I'm working on a fix now and hopefully will be done shortly. I'd be super curious how you reproduced it.

[philr]

@brixen Thanks - I can confirm that this is now fixed with Rubinius 3.99.

I first spotted this issue running the tests for tzinfo on Rubinius 3.93 (see https://travis-ci.org/tzinfo/tzinfo/jobs/331588292#L539). The test code above is based on the LocalTime, LocalDateTime, LocalTimestamp and Localized types from tzinfo.

The tzinfo tests now pass on Rubinius 3.99 (https://travis-ci.org/tzinfo/tzinfo/jobs/339829915).

[brixen]

@philr well, thanks for opening the issue and providing the repro, it was a huge help in fixing it! ❤️