From: "shugo (Shugo Maeda)" <redmine@...>
Date: 2012-08-23T13:08:03+09:00
Subject: [ruby-core:47292] [ruby-trunk - Bug #6907] Another problem with super


Issue #6907 has been updated by 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.

----------------------------------------
Bug #6907: Another problem with super
https://bugs.ruby-lang.org/issues/6907#change-28997

Author: tenderlovemaking (Aaron Patterson)
Status: Closed
Priority: Normal
Assignee: shugo (Shugo Maeda)
Category: 
Target version: 
ruby -v: ruby 2.0.0dev (2012-08-23 trunk 36786) [x86_64-darwin12.0.0]


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.


-- 
http://bugs.ruby-lang.org/