Bug #6907: Another problem with super

• Status: Closed
• Assignee: shugo (Shugo Maeda)
• Target version: -
• ruby -v: ruby 2.0.0dev (2012-08-23 trunk 36786) [x86_64-darwin12.0.0]

[tenderlovemaking (Aaron Patterson)]

I found another problem with super since r36640, but I don't know how to fix it. Shugo, or ko1, can you help me?

Since r36640, I can't call super in a thread. For example:

class Hoge
def bar
"hoge"
end
end

class Foo < Hoge
def bar
Thread.new { super }.join.value
end
end

puts Foo.new.bar

I'm not sure how to take threads into account in the loop looking through the cfps. I've read vm_search_superclass, but I don't understand. I've attached a patch that fails.

[shugo (Shugo Maeda)]

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

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

---

• insns.def (invokesuper): reverted r36640 partially to make super
  in a thread work correctly. [ruby-core:47284] [Bug #6907]

• test/ruby/test_super.rb: related test.

[shugo (Shugo Maeda)]

tenderlovemaking (Aaron Patterson) wrote:

I'm not sure how to take threads into account in the loop looking through the cfps. I've read vm_search_superclass, but I don't understand. I've attached a patch that fails.

The receiver lookup in r36640 is necessary only when instance_eval is used, so if frames knows whether instance_eval is used, the receiver lookup can be skipped.
However, I guess ko1 doesn't like to add a new flag to each frame.

I have reverted r36640 partially to solve this issue.
Bug #2402 may be a corner case which never occur in real applications.