Bug #3286
closedsegfault in method_missing -> method -> method_missing recursive loop
Description
=begin
the following code segfaults in 1.9.1 (and ruby-head) but works in 1.8.x:
class Foo
def bar
unknown_variable
end
def method_missing(m, *args)
bar
end
end
Thread.new do
begin
Foo.new.meow
rescue SystemStackError
p "raised"
exit
end
end
while true
sleep 1
end
ruby -v /tmp/fail.rb
ruby 1.8.6 (2010-02-05 patchlevel 399) [i686-linux]
"raised"
ruby -v /tmp/fail.rb
ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-linux]
"raised"
ruby -v /tmp/fail.rb
ruby 1.9.1p378 (2010-01-10 revision 26273) [i686-linux]
zsh: segmentation fault ruby -v /tmp/fail.rb
ruby -v /tmp/fail.rb
ruby 1.9.3dev (2010-05-13 trunk 27786) [i686-linux]
zsh: segmentation fault ruby -v /tmp/fail.rb
=end
Updated by dominikh (Dominik Honnef) over 14 years ago
=begin
Oh, nearly forgot it: It does not segfault if I don't use threads. It also does not segfault in a normal infinite recursive loop, i.e. no method_missing
=end
Updated by mame (Yusuke Endoh) over 14 years ago
- Target version set to 1.9.2
=begin
Hi,
This duplicates #1813. This issue also occurs on trunk.
Essentially, infinite recursion may cause segv. The segv is rescued
by using sigaltstack on Linux, but it will not on platform where
sigaltstack is not available (such as windows).
So if you want to write a portable ruby script, you should not depend
on SystemStackError.
Even in Linux, sigaltstack is set only for main thread. The segv
that occurs on sub threads leads to core dump. I don't know the
reason why sigaltstack is not used on sub threads, but I guess it is
merely forgotten.
--
Yusuke Endoh mame@tsg.ne.jp
=end
Updated by mame (Yusuke Endoh) over 14 years ago
- Status changed from Open to Closed
=begin
This issue was solved with changeset r27789.
Charlton, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
=end