Bug #7988

Module#prepend(Module) and instance_method causes Segmentation fault

Added by Nobuhiro IMAI about 1 year ago. Updated about 1 year ago.

Target version:-
ruby -v:ruby 2.1.0dev (2013-02-28 trunk 39535) [x86_64-linux] Backport:


$ gdb ruby
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x8664-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /home/nov/.rvm/rubies/ruby-head/bin/ruby...done.
(gdb) run -e 'Module.new{prepend Module.new}.instance
Starting program: /home/nov/.rvm/rubies/ruby-head/bin/ruby -e 'Module.new{prepend Module.new}.instancemethod(:foo)'
[Thread debugging using libthread
db enabled]
Using host libthreaddb library "/lib/x8664-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7ff8700 (LWP 15361)]

Program received signal SIGSEGV, Segmentation fault.
rbclassreal (cl=0) at object.c:175
175 while ((RBASIC(cl)->flags & FLSINGLETON) || BUILTINTYPE(cl) == TICLASS) {
(gdb) bt
#0 rb
classreal (cl=0) at object.c:175
#1 rb
classreal (cl=cl@entry=8783240) at object.c:171
#2 0x00007ffff7ac8c99 in rb
classname (klass=klass@entry=8783240) at variable.c:380
#3 0x00007ffff79bf07e in rb
printundef (klass=klass@entry=8783240, id=id@entry=17464, scope=scope@entry=0) at evalerror.c:216
#4 0x00007ffff79c5518 in mnew (klass=8783240, klass@entry=8783400, obj=obj@entry=52, id=17464, mclass=6644080, scope=0) at proc.c:976
#5 0x00007ffff79c7d66 in rbmodinstancemethod (mod=8783400, vid=4470796) at proc.c:1318
#6 0x00007ffff7ae84ff in vm
callcfuncwithframe (th=th@entry=0x601680, regcfp=regcfp@entry=0x7ffff7fd8f70, ci=ci@entry=0x8696c8) at vminsnhelper.c:1438
#7 0x00007ffff7af5c5d in vmcallcfunc (ci=0x8696c8, regcfp=0x7ffff7fd8f70, th=0x601680) at vminsnhelper.c:1528
#8 vmcallmethod (th=0x601680, cfp=0x7ffff7fd8f70, ci=0x8696c8) at vminsnhelper.c:1720
#9 0x00007ffff7aecff4 in vm
execcore (th=0x601680, initial=initial@entry=0) at insns.def:1017
#10 0x00007ffff7af0e9a in vm
exec (th=0x7ffff7ffa5e8, th@entry=0x601680) at vm.c:1175
#11 0x00007ffff7af818e in rbiseqevalmain (iseqval=iseqval@entry=8784040) at vm.c:1423
#12 0x00007ffff79bddda in ruby
execinternal (n=0x8608a8) at eval.c:250
#13 0x00007ffff79bf37d in ruby
execnode (n=n@entry=0x8608a8) at eval.c:315
#14 0x00007ffff79c144c in ruby
run_node (n=0x8608a8) at eval.c:307
#15 0x000000000040091b in main (argc=3, argv=0x7fffffffde98) at main.c:36

Associated revisions

Revision 39599
Added by Nobuyoshi Nakada about 1 year ago

proc.c: revert r39224


#1 Updated by Nobuhiro IMAI about 1 year ago

I found that this caused by r39224.

#2 Updated by Nobuyoshi Nakada about 1 year ago

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

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

proc.c: revert r39224

Also available in: Atom PDF