From: b g <bg_rubyposter_123456@...>
Date: 2004-05-25T04:59:33+09:00
Subject: Re: [PATCH] fixed SIG_SEGV in check_stack() in eval.c


--- Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
> 
> In message "[PATCH] fixed SIG_SEGV in check_stack() in eval.c"
>     on 04/05/22, b g <bg_rubyposter_123456@yahoo.com> writes:
> 
> |I was getting a crash at 'JUMP_TAG(state);' in
> |check_stack() in eval.c because prot_tag was NULL. 
> |The JUMP_TAG macro goes right after prot_tag without
> |checking it to be a valid pointer.  *CRASH*
> |
> |Attached is my very simple fix.  There's probly a
> |better way (I don't know why prot_tag is NULL in this
> |case, should it be?), but the patch below works for
> |me.
> 
> It's probably caused by prot_tag left uninitialized by the
> application.  Can you show us the portion of your application code
> that inistalize/call Ruby interpreter?
> 
> 							matz.

I'll go did out the initialization code in a momemnt.

I forgot to mention two additional things in my original post.
Hopefully these will be helpful:

This runs on SunOS 5.8:

$ uname -a
SunOS dufus 5.8 Generic_108528-23 sun4u sparc SUNW,Sun-Fire-280R Solaris

(I noticed some #ifdef'd behavior that was different for Suns surrounding
the use of setjmp/longjmp.  Perhaps running on Sun is relevant.)

And below is the ruby script that is being called from C.  Note that all the
global vars mentioned in the comments are defined by C before calling the
Ruby script.  Some of the vars are "inputs" to Ruby, some are "outputs" written
by Ruby.  I could make these parameters to a method call, but chose globals to
test performance.  (This will be called millions of times by my app, and I want
to see how fast Ruby is.  Turns out each invocation of the script below takes
about 26uS.  Pretty good.)

#   Defined by application before calling, and after 'def bg_compare' is complete:
#  
#   Each of these vars is rb_define_variable()'d after having done a
#   rb_float_new() to create Float objects in the Ruby interp.  Prior to each
#   rb_funcall() on Ojbect::bg_compare, the C-side vars are loaded with real
#   values
#
#   $l_lay  = 69.69;    $l_src  = 69.70;    $l_err  = 0.0;
#   $w_lay  = 69.69;    $w_src  = 69.70;    $w_err  = 0.0;
#   $as_lay = 69.69;    $as_src = 69.70;    $as_err = 0.0;
#   $ad_lay = 69.69;    $ad_src = 69.70;    $ad_err = 0.0;
#   $ps_lay = 69.69;    $ps_src = 69.70;    $ps_err = 0.0;
#   $pd_lay = 69.69;    $pd_src = 69.70;    $pd_err = 0.0;

def bg_compare
  loc_err=($l_lay-$l_src).abs/$l_src
  if loc_err>0.0001 then
    $l_err=loc_err
  end
  loc_err=($w_lay-$w_src).abs/$w_src
  if loc_err>0.0001 then
    $w_err=loc_err
  end
  loc_err=($as_lay-$as_src).abs/$as_src
  if loc_err>0.0001 then
    $as_err=loc_err
  end
  loc_err=($ad_lay-$ad_src).abs/$ad_src
  if loc_err>0.0001 then
    $ad_err=loc_err
  end
  loc_err=($ps_lay-$ps_src).abs/$ps_src
  if loc_err>0.0001 then
    $ps_err=loc_err
  end
  loc_err=($pd_lay-$pd_src).abs/$pd_src
  if loc_err>0.0001 then
    $pd_err=loc_err
  end
end



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/