Bug #5236

Including a module in a superclass after it has been included in a subclass leads to infinite recursion if the module uses `super`

Added by Myron Marston about 4 years ago. Updated over 2 years ago.

[ruby-core:39132]
Status:Closed
Priority:Normal
Assignee:Nobuyoshi Nakada
ruby -v:1.9.x Backport:

Description

Under these particular circumstances, you get infinite recursion and a system stack error on 1.9 but not 1.8:

  • Create a module that has a method that uses super
  • Include that module in a class after it has already been included in one of its subclasses
  • Instantiate an object of said subclass and call the method

On 1.8, the super works as expected. On 1.9 you get a SystemStackError. Here's example code that demonstrates the issue:

example.rb

module MyModule
def some_method; super; end
end

class MyBaseClass; end

class MySubClass < MyBaseClass;
include MyModule
end

To trigger this bug, we must include the module in the base class after

the module has already been included in the subclass. If we move this line

above the subclass declaration, this bug will not occur.

MyBaseClass.send(:include, MyModule)

MySubClass.new.some_method

The output

➜ ruby --version
ruby 1.8.7 (2011-02-18 patchlevel 334) [i686-darwin10.6.0]
➜ ruby example.rb
example.rb:2:in some_method': super: no superclass methodsome_method' for #MySubClass:0x1001bc2d0 (NoMethodError)
from example.rb:2:in `some_method'
from example.rb:13

➜ ruby --version
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.6.0]
➜ ruby example.rb
example.rb:2: stack level too deep (SystemStackError)

I've tried it on 1.9.3.preview-1 and I get the SystemStackError there, too. I would expect 1.9 to act like 1.8 here, and not infinitely recurse on itself.


Related issues

Related to Ruby trunk - Bug #3351: stack overflow on super Closed
Related to Ruby trunk - Feature #1586: Including a module already present in ancestors should not be ignored Assigned 06/07/2009

History

#1 Updated by Paul Annesley almost 4 years ago

This bug causes a lot of trouble for RSpec developers and end users alike:
https://github.com/rspec/rspec-rails/issues/371#issuecomment-1430232

It'd be great to see it fixed on Ruby's side.

Cheers!
Paul

#2 Updated by Koichi Sasada over 3 years ago

  • Assignee set to Koichi Sasada
  • Target version set to 2.0.0

#3 Updated by Shyouhei Urabe over 3 years ago

  • Status changed from Open to Assigned

#4 Updated by Koichi Sasada almost 3 years ago

  • Assignee changed from Koichi Sasada to Nobuyoshi Nakada

nobu, could you check it?

#5 Updated by Nobuyoshi Nakada over 2 years ago

  • Status changed from Assigned to Closed

Already fixed probably at r36595 etc.

Also available in: Atom PDF