Issue #2258 has been updated by Suraj Kurapati.


Hi,

The segfault mentioned in my previous message no longer occurs
with the newer Ruby @ SVN r25457 plus my SET_STACK_END patch.

The ruby-ucontext-full.tgz example now runs to completion
without a segfault.  However, an IO exception is raised 
during the call to Kernel.require('date') as follows:

Ruby: require 'hello' begin
~~~~> Hello World!  The time is 2009-10-24 18:52:00 -0700.
~~~~> Doing relay from /home/sun/lab/ruby-ucontext/hello.rb:3
Relay: ruby => main
Relay: main <= ruby
Relay: main => ruby
Relay: ruby <= main
~~~~> OMG, back from main!! :-)
rb_require('./hello.rb') failed with status=6
... because an exception was raised:
#<IOError: closed stream>
/home/sun/lab/ruby-ucontext/hello.rb:7:in `require'
/home/sun/lab/ruby-ucontext/hello.rb:7:in `<top (required)>'
Ruby: require 'hello' end

The corresponding GDB backtrace for this exception shows
really strange file names (which seem to be source lines
from a previously read file --- the standard "date.rb"):

#0  rb_raise (exc=140756320, fmt=0x8185b03 "closed stream") at error.c:1150
[...]
#14 0x080ac3a1 in yycompile (parser=0x86af230, f=0x86af158 "  # The method will attempt to parse a date-time from the String\n", line=1) at parse.y:5035
#15 0x080ac7c6 in rb_parser_compile_file (vparser=140736400, f=0x86af158 "  # The method will attempt to parse a date-time from the String\n", file=140736380, start=1) at parse.y:5164
#16 0x080f0e73 in load_file_internal (arg=140517824) at ruby.c:1582
#17 0x08064571 in rb_ensure (b_proc=0x80f08c3 <load_file_internal>, data1=140517824, e_proc=0x80f0f02 <restore_lineno>, data2=1) at eval.c:695
#18 0x080f0f69 in load_file (parser=140736400, fname=0x86af158 "  # The method will attempt to parse a date-time from the String\n", script=0, opt=0x86021f8) at ruby.c:1610
#19 0x080f0fa3 in rb_load_file (fname=0x86af158 "  # The method will attempt to parse a date-time from the String\n") at ruby.c:1618
#20 0x08065a21 in rb_load_internal (fname=140736600, wrap=0) at load.c:289
[...]

Is this another case of memory corruption?  Or perhaps this is
a side-effect of setjmp/longjmp being used for exception handling?

Thanks for your consideration.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2258

----------------------------------------
http://redmine.ruby-lang.org