The file is: ./spec/frozen/language/return_spec.rb I don't know how to describe which one other than the first describe that starts "in a Thread" Currently it does: The return keyword in a Thread - raises a LocalJumpError if used to exit a threadSEGV recieved in SEGV handler unknown: [BUG] Segmentation fault Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems On Jul 9, 2009, at 2:35 PM, Laurent Sansonetti wrote:
Hi Perry,
Which spec are you talking about specifically?
Laurent
On Jul 9, 2009, at 5:56 AM, Perry Smith wrote:
The spec says that a 'return' from a thread should raise a LocalJumpError.
Looking at the code for RETURN_NODE in compiler.cpp, the question of "Is this a thread" is never asked. And, I guess this exception is only for the top level block of the thread since a function called from the block could do a return.
I looked briefly at the Thread create process and I didn't see anything that flagged the block passed as the top level block for the thread.
The testcase causes a segmentation fault. I looked at the signal handler too and it appears as if it is "lets do this for now and address it later" code. The SEGV fault handler simply sets a flag and returns. The return will put us back where we were just at so we immediately seg fault again and then we do an exit -- with no core file.
I don't see the value of catching SEGV in the first place unless the underlying Ruby code has asked us to do that. I think that would generally apply to all signals.
Perry
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel