Bug #2420

super call may use wrong receiver object

Added by nobu (Nobuyoshi Nakada) over 2 years ago. Updated 12 months ago.

[ruby-core:27000]
Status:Closed Start date:12/02/2009
Priority:Normal Due date:
Assignee:ko1 (Koichi Sasada) % Done:

0%
Category:-
Target version:2.0.0
ruby -v:ruby 1.9.2dev (2009-12-01 trunk 25970) [i386-darwin9.0]

Description

The code below prints:
C
main
Object::m

which means that the super calls the instance method B#m on a receiver that is not an instance of B. It's not what makes the super call to pick the main object as a receiver in this case. I would expect it to use the "self" object that the block captures, i.e. the class object C, and thus an exception "no superclass method `m' (NoMethodError)" should be raised.

class B
  def m
    p self
    puts self.class.to_s + '::m'
  end
end

class C < B
  q = Proc.new do
    p self
    super()
  end

  mq = define_method :m, &q

  mq.call
end


BTW: The behavior is even worse in Ruby 1.9:
ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-mswin32]
C
a.rb:11:in `==': wrong number of arguments(0 for 1) (ArgumentError)
        from a.rb:11:in `block in <class:C>'
        from a.rb:16:in `call'
        from a.rb:16:in `<class:C>'
        from a.rb:8:in `<main>'

Related issues

duplicated by ruby-trunk - Bug #3136: reuse of singleton method definition causes SEGV Closed 04/12/2010

Associated revisions

Revision 28043
Added by mame (Yusuke Endoh) almost 2 years ago

* insns.def (invokesuper): check consistency between class of self and class of method being invoked by super. This is temporary measure for YARV. See [ruby-core:30313] in detail. See [ruby-dev:40959] [ruby-dev:39772] [ruby-core:27000] [ruby-core:27230] * vm_insnhelper.c (vm_search_superclass): ditto.

Revision 29063
Added by wanabe (_ wanabe) almost 2 years ago

* vm.c (vm_define_method): copy iseq to avoid overwriting iseq->klass. #2502, #3136. see #2420.

Revision 29063
Added by wanabe (_ wanabe) almost 2 years ago

* vm.c (vm_define_method): copy iseq to avoid overwriting iseq->klass. #2502, #3136. see #2420.

History

#1
Updated by mame (Yusuke Endoh) almost 2 years ago

  • Assignee changed from nobu (Nobuyoshi Nakada) to ko1 (Koichi Sasada)
  • Target version set to 2.0.0
Hi,

I committed r28043 as temporary measure for 1.9.2 release.
This will be fixed correctly at 1.9.3 or later.
See [Bug #2502] [Bug #3136] in detail.

-- 
Yusuke Endoh <mame@tsg.ne.jp>

#2
Updated by wanabe (_ wanabe) almost 2 years ago

  • Status changed from Open to Closed
This issue was solved with changeset r29063.
Yusuke, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

#3
Updated by wanabe (_ wanabe) almost 2 years ago

  • Status changed from Closed to Open

#4
Updated by shyouhei (Shyouhei Urabe) over 1 year ago

Hi, can I close this?

[ruby-core:36973]#5
Updated by ko1 (Koichi Sasada) 12 months ago

wanabe-san, Should we keep it open or not?

[ruby-core:36975]#6
Updated by nobu (Nobuyoshi Nakada) 12 months ago

  • Status changed from Open to Closed
This issue has gone away.

Also available in: Atom PDF