Bug #3351

stack overflow on super

Added by Serge Balyuk almost 4 years ago. Updated about 1 year ago.

[ruby-core:30450]
Status:Open
Priority:Low
Assignee:Koichi Sasada
Category:core
Target version:next minor
ruby -v:ruby 1.9.3dev (2010-05-26 trunk 28028) [i686-linux] Backport:

Description

=begin
It looks like super behavior is a bit different in 1.8 and 1.9. Please find the example below:

class Base
def foo
puts "bar"
end
end

module Override
def foo
puts "override"
super
end
end

class A < Base
end

class B < A
end

B.send(:include, Override)
A.send(:include, Override)

B.new.foo

ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux] output:

override
override
bar

and ruby 1.9.3dev (2010-05-26 trunk 28028) [i686-linux] output:

....
override
override
override
override
override
super.rb:9: stack level too deep (SystemStackError)

Hope that helps.
=end

super.rb Magnifier (217 Bytes) Serge Balyuk, 05/27/2010 03:45 PM


Related issues

Related to ruby-trunk - Bug #2502: strange behavior of anonymous class inside a proc Closed 12/19/2009
Related to ruby-trunk - Bug #5236: Including a module in a superclass after it has been incl... Closed 08/27/2011
Related to ruby-trunk - Feature #1586: Including a module already present in ancestors should no... Assigned 06/07/2009

Associated revisions

Revision 36612
Added by Shugo Maeda over 1 year ago

  • insns.def (invokesuper): don't skip the same class. instead, use rbmethodentrygetwith_omod() to avoid infinite loop when super is used with refinements. [Bug #3351]

History

#1 Updated by Marc-Andre Lafortune almost 4 years ago

  • Category set to core
  • Priority changed from Normal to Low

=begin
I thought I had submitted that bug, actually, but seems I forgot!

Just to clarify: this happens when a module appears twice in the list of ancestors. Ruby typically forbids this, but if the module is included in just the right order, it is possible. In the example given, invert the two includes and Override is included only once.
=end

#2 Updated by Serge Balyuk almost 4 years ago

=begin
Hi Marc-Andre,

Yes, exactly. Very rare situation. This is the simplified version of include sequence that I observed in one specific rails/rspec use case. And with inverted includes everything works like charm.

Thanks

=end

#3 Updated by Yui NARUSE almost 3 years ago

  • Status changed from Open to Assigned
  • Assignee set to Koichi Sasada
  • Target version changed from 2.0.0 to 1.9.3

#4 Updated by Yura Sokolov almost 3 years ago

I had catched by this with rails/sequel/custom backend for delayed_jobs.
After figuring, I ought to do some manipulations with requiring my initializators, and that looks ugly a bit.

#5 Updated by Koichi Sasada almost 3 years ago

  • Target version changed from 1.9.3 to 2.0.0

I'll challenge this issue on 1.9.4. Sorry.

#6 Updated by Shugo Maeda over 1 year ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r36612.
Serge, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • insns.def (invokesuper): don't skip the same class. instead, use rbmethodentrygetwith_omod() to avoid infinite loop when super is used with refinements. [Bug #3351]

#7 Updated by Shugo Maeda over 1 year ago

  • Status changed from Closed to Open

In HEAD of trunk, stack overflow doesn't occur, but Override#foo is called only once.
So I reopen this ticket.

#8 Updated by Koichi Sasada over 1 year ago

shugo-san, do you know why Override#foo called only once?

#9 Updated by Yusuke Endoh over 1 year ago

  • Status changed from Open to Assigned
  • Assignee changed from Koichi Sasada to Shugo Maeda

Shugo-san, ko1, what's the status?
Do you think this issue important?

Yusuke Endoh mame@tsg.ne.jp

#10 Updated by Shugo Maeda over 1 year ago

  • Assignee changed from Shugo Maeda to Yukihiro Matsumoto

mame (Yusuke Endoh) wrote:

Shugo-san, ko1, what's the status?

Override#foo is called only once, because in the SVN trunk, if a method found by super is the current method, it's skipped to avoid an infinite loop. The check was introduced for super in a refinement. Without it, super in a refinement causes an infinite loop.

Do you think this issue important?

I don't think so. Can I leave it as is, Matz?

#11 Updated by Anonymous over 1 year ago

Hi,

In message "Re: [ruby-trunk - Bug #3351] stack overflow on super"
on Thu, 13 Dec 2012 14:24:21 +0900, "shugo (Shugo Maeda)" redmine@ruby-lang.org writes:

|> Do you think this issue important?
|
|I don't think so. Can I leave it as is, Matz?

OK.

                        matz.

#12 Updated by Shugo Maeda over 1 year ago

  • Status changed from Assigned to Open
  • Assignee deleted (Yukihiro Matsumoto)
  • Target version changed from 2.0.0 to next minor

#13 Updated by Koichi Sasada about 1 year ago

  • Assignee set to Koichi Sasada

Also available in: Atom PDF