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.