Brent, Sylvain,

I don't think that valgrind is all that useful for this kind of
problem.  Valgrind will likely spew out a whole lot of warnings or
errors of the type "read from uninitialised memory location".  The
reason is the conservative garbage collector.  A conservative
collector scans all allocated memory (heap/stacks/..) searching for
values that look like pointers.  This includes memory that has been
allocated, but has not been written to yet.  In the context of a
program, one generally (unless reading out external input which is
mapped in memory for example) does not want to read from uninitialized
memory locations and in that case it is likely a bug in the program.
In the context of a conservative collector, reading from uninitialized
memory is part of the way a conservative collector works, and is
correct behaviour.  If the segmentation fault is actually coming from
a bug in the collector, valgrind won't be useful, or at least not
effective for tracking the bug down.  It's been a while since last
time I used valgrind, but if I remember correctly, a suppression file
will let you for example ignore the so-called 'errors' valgrind
detects in the collector code, but then you also won't find the
problematic code in the collector.... if that's where the bug is, of
course.  Valgrind is a really nice and really good tool, but not
useful for tracking down bugs in a (conservative) collector.

Kind regards,
Ruben



At Sun, 3 Jun 2007 01:31:43 +0900,
Brent Roman wrote:
> 
> Sylvain,
> 
> I plan to try valgrind on a ruby interpreter built for the x86 with all compiler 
> optimization disabled next week.  I'd never heard of valgrind before.
> 
> Note that ggarra / advancedsl.com.ar suggested this off-list a few
> days before you did.
> 
> It does sound promising.  
> 
> I'm hopeful that it might lead us to the cause of what appears
> to be a wild VAULE pointer write.
> 
> - brent
>  
> 
> 
> > If you can run your application on x86 and still have the crash, run the 
> > interpreter under valgrind. You'll have to generate a suppression file 
> > beforehand though.
> > -- 
> > Sylvain
> 
> -- 
>  Brent Roman
>  Software Engineer                 Tel: 831 775 1808
>  425 Clinton St., Santa Cruz,      California, 95062
>  mailto:brent / mbari.org  http://www.mbari.org/~brent
> 
>