Bug #7009: Crash in method_missing

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -
• ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.4.0]
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[alexcoplan (Alex Coplan)]

=begin
Given the following code:

def method_missing(sym, *args)
foo(sym, *args)
end

bar

When (({bar})) is called, it triggers method_missing (because bar is undefined). Inside method_missing, it calls (({foo})) (another undefined method), and that in turn calls method_missing, but this time the method name and the rest of the arguments are passed back to method missing. This results in an ever-increasing number of arguments. If I add a debug line like so:

def method_missing(sym, *args)
print "#{sym} #{args}\n"
foo(sym, *args)
end

bar # undefined method

then this is the first few lines of output:

bar []
foo [:bar]
foo [:foo, :bar]
foo [:foo, :foo, :bar]
foo [:foo, :foo, :foo, :bar]

The expected result is that it should report a SystemStackError

mm.rb:2: stack level too deep (SystemStackError)

The actual result is this:

mm.rb:2: [BUG] Segmentation fault
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.4.0]

-- Control frame information -----------------------------------------------
c:2695 p:0037 s:10775 b:9428 l:009427 d:009427 METHOD thing.rb:3
c:2694 p:---- s:9423 b:9423 l:009422 d:009422 FINISH
c:2693 p:0037 s:9421 b:9421 l:009420 d:009420 METHOD thing.rb:3
c:2692 p:---- s:9416 b:9416 l:009415 d:009415 FINISH

That crash log goes on a lot longer and I will attach both the ruby crash log and the system crash log.

[shyouhei (Shyouhei Urabe)]

• Priority changed from Normal to 3

This is a known issue, hard to fix. Patches are welcomed very much.

[nobu (Nobuyoshi Nakada)]

• Description updated (diff)

[mame (Yusuke Endoh)]

• Status changed from Open to Assigned
• Assignee set to kosaki (Motohiro KOSAKI)
• Target version set to 2.0.0

I cannot reproduce on Linux.
I wonder if altstack does not work on os x.
Kosaki-san, do you know anything about this?

--
Yusuke Endoh [e-mail]

[kosaki (Motohiro KOSAKI)]

• Category set to core
• Assignee changed from kosaki (Motohiro KOSAKI) to nobu (Nobuyoshi Nakada)
• Target version changed from 2.0.0 to 1.9.3

This issue works on trunk.

% ./ruby-trunk ../test.rb
../test.rb:3: stack level too deep (SystemStackError)

Recently nobu changed stack overflow detection logic, I suspect it also fixes this issue.
Nobu, if yes, can you please tell us exact commit number what revision should be backported.

[nobu (Nobuyoshi Nakada)]

(12/11/09 1:31), kosaki (Motohiro KOSAKI) wrote:

Recently nobu changed stack overflow detection logic, I suspect it also fixes this issue.
Nobu, if yes, can you please tell us exact commit number what revision should be backported.

I can't reproduce it with the recent 1.9.3, but if it was the case,
it might be one/both of r37072 and r37079,37080,37042 set.

--
Nobu Nakada

[naruse (Yui NARUSE)]

• Target version changed from 1.9.3 to 2.6

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[jeremyevans0 (Jeremy Evans)]

• Status changed from Assigned to Closed