Bug #9109

extend したモジュールメソッドと RSpec の let で 2 つ同名を使ったときに segmentation fault になる

Added by sunao tanabe over 1 year ago. Updated about 1 year ago.

[ruby-dev:47804]
Status:Assigned
Priority:Low
Assignee:Nobuyoshi Nakada
ruby -v:ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin11.4.2] Backport:1.9.3: REQUIRED, 2.0.0: REQUIRED

Description

=begin

以下のコードで segmentation fault を起こします。

require 'rspec'

module ExtendModule
def foo
'foo'
end

def bar
'bar'
end
end

describe 'foo' do
extend ExtendModule
let(:foo) { foo }
let(:bar) { bar }
it { foo.should be 'foo' }
it { bar.should be 'bar' }
end

実行結果

$ bundle exec rspec
FSegmentation fault: 11

RSpec version 2.14.7 (現時点の最新安定板)

期待する挙動

segmentation fault せず SystemStackError となる (同名が 1 つの場合の挙動から推測)

=end


Related issues

Duplicated by Ruby trunk - Bug #9900: Segmentation fault with recursive reference of a hash Closed 06/04/2014

Associated revisions

Revision 43707
Added by Nobuyoshi Nakada over 1 year ago

eval_intern.h: refine stack overflow detection

  • eval_intern.h (TH_PUSH_TAG, TH_EXEC_TAG): refine stack overflow detection. chain local tag after setjmp() successed on it, because calling setjmp() also can overflow the stack. [Bug #9109]
  • vm_eval.c (rb_catch_obj): now th->tag points previous tag until TH_EXEC_TAG().

Revision 43707
Added by Nobuyoshi Nakada over 1 year ago

eval_intern.h: refine stack overflow detection

  • eval_intern.h (TH_PUSH_TAG, TH_EXEC_TAG): refine stack overflow detection. chain local tag after setjmp() successed on it, because calling setjmp() also can overflow the stack. [Bug #9109]
  • vm_eval.c (rb_catch_obj): now th->tag points previous tag until TH_EXEC_TAG().

History

#1 Updated by Shota Fukumori over 1 year ago

  • Priority changed from Normal to Low

運が悪いとsystemstackerrorにならず SEGV が発生する既知の現象に見えます。

#2 Updated by Nobuyoshi Nakada over 1 year ago

_th.tagをセットした後、EXEC_TAG()中のsetjmp()の中でスタックオーバーフローしているようですね。
これはどうしたものかなぁ。

#3 Updated by Nobuyoshi Nakada over 1 year ago

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

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


eval_intern.h: refine stack overflow detection

  • eval_intern.h (TH_PUSH_TAG, TH_EXEC_TAG): refine stack overflow detection. chain local tag after setjmp() successed on it, because calling setjmp() also can overflow the stack. [Bug #9109]
  • vm_eval.c (rb_catch_obj): now th->tag points previous tag until TH_EXEC_TAG().

#4 Updated by Nobuyoshi Nakada over 1 year ago

とりあえずstack overflowでSEGVするのは直ったと思います。
代わりに [BUG] vm_call_cfunc - cfp consistency error が出るようになりましたが、それはまた別件なので。

#5 Updated by Tomoyuki Chikanaga over 1 year ago

  • Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN to 1.9.3: UNKNOWN, 2.0.0: REQUIRED

#6 Updated by Hiroshi Shirosaki over 1 year ago

  • Status changed from Closed to Assigned
  • Assignee set to Nobuyoshi Nakada

=begin

[i386-mingw32] では、SEGVになってしまうようです。
これは直るのでしょうか?
以下、gdbの出力です。

sh-3.1$ gdb -args ./ruby -v -I. -I ../../../ruby/lib -I .ext/i386-mingw32 -e 'h = {a: ->{h[:a].call}};h[:a].call'
GNU gdb (rubenvb-4.7.2-release) 7.5.50.20120920-cvs
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 "i686-w64-mingw32".
For bug reporting instructions, please see:
mingw-w64-public@lists.sourceforge.net...
Reading symbols from c:\Users\h.shirosaki\work\rubyinstaller\sandbox\ruby21_build\ruby.exe...done.
(gdb) r
Starting program: c:\Users\h.shirosaki\work\rubyinstaller\sandbox\ruby21_build\ruby.exe -v -I. -I ../../../ruby/lib -I .
ext/i386-mingw32 -e "h = {a: ->{h[:a].call}};h[:a].call"
[New Thread 2132.0x1a5c]
[New Thread 2132.0x17d4]
ruby 2.2.0dev (2014-01-07 trunk 44522) [i386-mingw32]

Program received signal SIGSEGV, Segmentation fault.
vm_exec_core (th=0x7c6670, initial=initial@entry=0) at ../../../ruby/vm_exec.c:46
46 {
(gdb) bt 20
#0 vm_exec_core (th=0x7c6670, initial=initial@entry=0) at ../../../ruby/vm_exec.c:46
#1 0x640c709c in vm_exec (th=th@entry=0x7c6670) at ../../../ruby/vm.c:1307
#2 0x640c85eb in invoke_block_from_c (defined_class=4, cref=0x0, blockptr=0x0, argv=0x50a1a0, argc=0, self=8171304,
block=0x2c258b8, th=0x7c6670) at ../../../ruby/vm.c:732
#3 vm_invoke_proc (th=0x0, th@entry=0x4, proc=0x2c258b8, proc@entry=0x0, self=8171304, defined_class=4, argc=0,
argv=0x50a1a0, blockptr=0x0) at ../../../ruby/vm.c:788
#4 0x640c869b in rb_vm_invoke_proc (th=0x4, proc=0x0, proc@entry=0x2c258b8, argc=5284256, argc@entry=0, argv=0x0,
argv@entry=0x50a1a0, blockptr=0x0) at ../../../ruby/vm.c:807
#5 0x63f9792e in proc_call (argc=0, argv=0x50a1a0, procval=45045816) at ../../../ruby/proc.c:786
#6 0x640bdd96 in vm_call_cfunc_with_frame (th=0x7c6670, reg_cfp=0x557a30, ci=)
at ../../../ruby/vm_insnhelper.c:1470
#7 0x640c2c96 in vm_exec_core (th=0x7c6670, initial=initial@entry=0) at ../../../ruby/insns.def:1028
#8 0x640c709c in vm_exec (th=th@entry=0x7c6670) at ../../../ruby/vm.c:1307
#9 0x640c85eb in invoke_block_from_c (defined_class=4, cref=0x0, blockptr=0x0, argv=0x50a18c, argc=0, self=8171304,
block=0x2c258b8, th=0x7c6670) at ../../../ruby/vm.c:732
#10 vm_invoke_proc (th=0x0, th@entry=0x4, proc=0x2c258b8, proc@entry=0x0, self=8171304, defined_class=4, argc=0,
argv=0x50a18c, blockptr=0x0) at ../../../ruby/vm.c:788
#11 0x640c869b in rb_vm_invoke_proc (th=0x4, proc=0x0, proc@entry=0x2c258b8, argc=5284236, argc@entry=0, argv=0x0,
argv@entry=0x50a18c, blockptr=0x0) at ../../../ruby/vm.c:807
#12 0x63f9792e in proc_call (argc=0, argv=0x50a18c, procval=45045816) at ../../../ruby/proc.c:786
#13 0x640bdd96 in vm_call_cfunc_with_frame (th=0x7c6670, reg_cfp=0x557a80, ci=)
at ../../../ruby/vm_insnhelper.c:1470
#14 0x640c2c96 in vm_exec_core (th=0x7c6670, initial=initial@entry=0) at ../../../ruby/insns.def:1028
#15 0x640c709c in vm_exec (th=th@entry=0x7c6670) at ../../../ruby/vm.c:1307
#16 0x640c85eb in invoke_block_from_c (defined_class=4, cref=0x0, blockptr=0x0, argv=0x50a178, argc=0, self=8171304,
block=0x2c258b8, th=0x7c6670) at ../../../ruby/vm.c:732
#17 vm_invoke_proc (th=0x0, th@entry=0x4, proc=0x2c258b8, proc@entry=0x0, self=8171304, defined_class=4, argc=0,
argv=0x50a178, blockptr=0x0) at ../../../ruby/vm.c:788
#18 0x640c869b in rb_vm_invoke_proc (th=0x4, proc=0x0, proc@entry=0x2c258b8, argc=5284216, argc@entry=0, argv=0x0,
argv@entry=0x50a178, blockptr=0x0) at ../../../ruby/vm.c:807
#19 0x63f9792e in proc_call (argc=0, argv=0x50a178, procval=45045816) at ../../../ruby/proc.c:786
(More stack frames follow...)
=end

#7 Updated by Usaku NAKAMURA about 1 year ago

  • Backport changed from 1.9.3: UNKNOWN, 2.0.0: REQUIRED to 1.9.3: REQUIRED, 2.0.0: REQUIRED

#8 Updated by Nobuyoshi Nakada 11 months ago

  • Duplicated by Bug #9900: Segmentation fault with recursive reference of a hash added

Also available in: Atom PDF