Bug #7988

Module#prepend(Module) and instance_method causes Segmentation fault

Added by Nobuhiro IMAI about 2 years ago. Updated almost 2 years ago.

[ruby-core:53038]
Status:Closed
Priority:Normal
Assignee:-
ruby -v:ruby 2.1.0dev (2013-02-28 trunk 39535) [x86_64-linux] Backport:

Description

$ 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/nov/.rvm/rubies/ruby-head/bin/ruby...done.
(gdb) run -e 'Module.new{prepend Module.new}.instance_method(:foo)'
Starting program: /home/nov/.rvm/rubies/ruby-head/bin/ruby -e 'Module.new{prepend Module.new}.instance_method(:foo)'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7ff8700 (LWP 15361)]

Program received signal SIGSEGV, Segmentation fault.
rb_class_real (cl=0) at object.c:175
175 while ((RBASIC(cl)->flags & FL_SINGLETON) || BUILTIN_TYPE(cl) == T_ICLASS) {
(gdb) bt
#0 rb_class_real (cl=0) at object.c:175
#1 rb_class_real (cl=cl@entry=8783240) at object.c:171
#2 0x00007ffff7ac8c99 in rb_class_name (klass=klass@entry=8783240) at variable.c:380
#3 0x00007ffff79bf07e in rb_print_undef (klass=klass@entry=8783240, id=id@entry=17464, scope=scope@entry=0) at eval_error.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 rb_mod_instance_method (mod=8783400, vid=4470796) at proc.c:1318
#6 0x00007ffff7ae84ff in vm_call_cfunc_with_frame (th=th@entry=0x601680, reg_cfp=reg_cfp@entry=0x7ffff7fd8f70, ci=ci@entry=0x8696c8) at vm_insnhelper.c:1438
#7 0x00007ffff7af5c5d in vm_call_cfunc (ci=0x8696c8, reg_cfp=0x7ffff7fd8f70, th=0x601680) at vm_insnhelper.c:1528
#8 vm_call_method (th=0x601680, cfp=0x7ffff7fd8f70, ci=0x8696c8) at vm_insnhelper.c:1720
#9 0x00007ffff7aecff4 in vm_exec_core (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 rb_iseq_eval_main (iseqval=iseqval@entry=8784040) at vm.c:1423
#12 0x00007ffff79bddda in ruby_exec_internal (n=0x8608a8) at eval.c:250
#13 0x00007ffff79bf37d in ruby_exec_node (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 almost 2 years ago

proc.c: revert r39224

Revision 39599
Added by Nobuyoshi Nakada almost 2 years ago

proc.c: revert r39224

History

#1 Updated by Nobuhiro IMAI about 2 years ago

I found that this caused by r39224.

#2 Updated by Nobuyoshi Nakada almost 2 years 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