Re: Ruby, pthreads, and HPUX 11

Incidentally, I just tried compiling Ruby 1.9, and it segfaults with the 
same error, in (more or less) the same place, and for the same reason 
(old_cref is getting clobbered). :(

- Jamis

Jamis Buck wrote:
> I'm finally trying to delve into the issue of Ruby not compiling 
> properly on HPUX (11, in my case) when --enable-pthreads is set. (This 
> is necessary in order to use, for instance, any Oracle module, since the 
> Oracle libs are compiled against pthreads).
> 
> This references ruby-talk:107425 and ruby-talk:115767 (see the stack 
> traces given in those threads).
> 
> I am compiling Ruby 1.8.2.
> 
> To review the issue: miniruby compiles fine, but when it is run, it dies 
> in either shellwords.rb or ftools.rb (not sure what the determining 
> factor is, in this case). I've managed to narrow it down and can get the 
> following to segfault consistently:
> 
>   miniruby -e "loop { break }"
> 
> It appears to be an issue with memory being clobbered during a longjmp 
> call. In the case of the one-liner above, the it is the longjmp that is 
> invoked as a result of the 'break'.
> 
> I've managed to narrow it down to the following. In eval.c, there is a 
> function "rb_yield_0" (line 4619). In "rb_yield_0", there is a variable 
> "old_cref", which is used to save the value of the global "ruby_cref" 
> (line 4645). On line 4727 an EXEC_TAG() is invoked (which does a setjmp, 
> I believe). At this point, the value of old_cref is correct.
> 
> Later, when the 'break' statement causes a longjmp to be executed, 
> execution resumes at line 4727. At this point, the value of old_cref is 
> incorrect (0x00000000). I put various trace statements throughout the 
> code (esp. rb_eval) and was able to see that the value in old_cref was 
> correct up to the very moment that longjmp was called.
> 
> Thus, it appears that something is occuring in the longjmp call that 
> clobbers the stack, but only when pthreads is linked in.
> 
> I am certainly in over my head here, and I have no idea where else to 
> look, or what else to try. I'm hoping the above summary will ring some 
> bells for someone, or at least suggest another avenue that I might try.
> 
> Thanks!
> 
> Jamis
> 


-- 
Jamis Buck
[e-mail]
http://www.jamisbuck.org/jamis