On Nov 28, 2003, at 12:14 PM, ts wrote:

>>>>>> "R" == Richard Kilmer <rich / infoether.com> writes:
>
> R> The saga continues:
> R> I am now running under 1.8.1 built from CVS built on Nov 24:
>
>  It will be faster if you can write a small program, to make possible 
> to
>  others to run it

Trust me, I would if I could.  This is intermittent.  We have a 12,000 
LOC
Ruby framework controlling over 150 Java VMs across a network via 
Jabber.

I just don't where where to begin to isolate the problem into a 
repeatable
example.  I can try.

>
> R> That section of protocol.rb seems like and odd place for reporting 
> such
> R> a fault:
>
>  Not really odd, the backtrace say that it segfault on return
>
> R> #9  0x080593c8 in localjump_destination (state=1, retval=4) at
>
>  state = 1  ==> return
>  retval = 4 ==> Qnil
>
>
> R> #5  0x4002947e in __pthread_sighandler () from 
> /lib/i686/libpthread.so.0
> R> #6  <signal handler called>
> R> #7  0xffffffff in ?? ()
> R> #8  0x40024762 in longjmp () from /lib/i686/libpthread.so.0
> R> #9  0x080593c8 in localjump_destination (state=1, retval=4) at
>
>  What do pthread here ?

Hm.  I don't know what is using pthread.  The only native library which 
is
being loaded that is not under my control (team-wise) is the postgres.so
I have wondering if that is an issue.  I don't think the active scripts
are using it, but its being required.  Could postgres.so cause a problem
like this?  Perhaps I can just rename this extension and put in a empty
postgres.rb file to fulfill the 'require'ment.

>
>  This backtrace don't seems related to a GC problem.
>
>
> Guy Decoux
>
>

Thanks for you reply Guy.