Re: Segmentation Fault in GC

Paul,

Thanks for looking at this.  Please see answers to your questions below:

> So the line numbers seem to be off by 15 lines or so.  Are you running a
> stock 1.6.8 or have you made changes?
>

I added a couple methods to gc.c to allow one to alter the
GC_MALLOC_LIMIT from within ruby with the syntax:

  GC.limit={new limit in bytes}

This explains why the line numbers don't match.
I've posted the updated gc.c source on our FTP site.
These line #'s should match those in the backtrace.

We typically run with the GC_MALLOC_LIMIT set at 2MB rather than 8MB
This saves us about 6MB of RAM.  On a 32MB machine, that was significant.

Note that we started observing the random GC segfaults long before
making any changes to gc.c


> Also, if you're going to be running 1.6, there two years worth of fixes
> in the latest 1.6 branch that aren't present in 1.6.8 (there was never a
> 1.6.9 released).  In particular, there are some GC changes.  I don't
> know if these changes would fix your problem or not.

I started with what I believe to be the latest, official ruby 1.6.8
snapshot at:

ftp://ruby-lang.org/pub/ruby/snapshot-1.6.tar.gz

Is there any official snapshot later than this one?


I've posted the following files on our anonymous FTP site at:

ftp://ftp.mbari.org/pub/brent
====
gc.c                  with GC.limit and GC.limit= methods
bt.07may14larv        gdb backtrace
btfull.07may14larv    gdb bt full  (full backtrace)
core.07may14larv      ARM process core dump at time of segfault
ruby-1.6.8-mbari.tgz  our complete, patched ruby source tree
termios.tgz           termios extension source
mbarilib.tgz          source for one, trivial 'C' extension I wrote

If there's any more info I can provide you, or anyone else kind
enough to look into this, please don't hesitate to ask.

-- 
 Brent Roman
 Software Engineer                 Tel: [phone]
 425 Clinton St., Santa Cruz,      California, 95062
 mailto:[e-mail]  http://www.mbari.org/~bren