Re: [Valgrind-users] Code memchecks clean, but core dumps under callgrind - help?

[Dave S. <dgs...@nu...>]

Folks,

Thanks for all your responses.  I _think_ I've got it figured out...

Olivier Ballereau writes:
 > Dave Steffen wrote:
 > > Compiler: GCC 3.4.6
 > >   Reading specs from /scratch/dgsteffen/local/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
 > >   Configured with: ../gcc-3.4.6/configure --prefix=/scratch/dgsteffen/local
 > >   Thread model: posix
 > >   gcc version 3.4.6
 > ...
 > > --7122-- Reading syms from /usr/lib/libstdc++.so.5.0.6 (0x403D000)
 > 
 > I think it can be a libstdc++ version problem. According to
 > <http://gcc.gnu.org/onlinedocs/libstdc++/abi.html>, G++ 3.4.6 ships
 > with libstdc++.so.6.0.3. Moreover, your GCC is configured with
 > --prefix=/scratch/dgsteffen/local (and seems to be installed there,
 > according to the specs file) and libstdc++ is loaded from /usr/lib.
 > 
 > This would explain why memcheck has no problem (the call to
 > operator new() is redirected to memcheck's own version), but causes
 > problem to callgrind.

 I think this is it.  I installed Valgrind on a different machine,
 using GCC 3.3 and doing some other environment things differently; on
 that machine, it seems to work.  I will investigate further.

Julian Seward writes:
[...]
 > What happens if you run it with --tool=none (instead of --tool=callgrind) ?
 > Does it work?

 Yes, this works just fine.

Olly Betts writes:
 > On 2006-11-01, Dave Steffen <dgs...@nu...> wrote:
 > > One additional piece of information: I haven't verified this yet, but
 > > it looks like there's just a wee bit of difference in the floating
 > > point results between running it normally and running it under
 > > memcheck; we're talking a few units-in-last-place, or numbers that are
 > > extremely close to zero.  I'm not panicking about this... yet... but
 > > it makes me nervous.
 > 
 > I don't think anyone has commented on this part yet, but it's probably
 > caused by a known feature of valgrind:
 > 
 > http://article.gmane.org/gmane.comp.debugging.valgrind/3108
 > 
 > I suspect this only affects x86 so if you see it on x86-64 or ppc it
 > may be a problem with valgrind's FP handling.

 Yes, I think you're right. We have seen similar things happen when we
 change compiler flags and such, particularly on data sets where the
 nonlinear math operations get a little touchy. :-)

 I'll stop worrying about the minor floating point stuff, and poke
 further at the environment and machine issues that might be causing
 the core dumps.

 Again, thanks very much folks.

----------------------------------------------------------------------
Dave Steffen, Ph.D.      
Software Engineer IV              Disobey this command!
Numerica Corporation
ph (970) 419-8343 x27    
fax (970) 223-6797                   - Douglas Hofstadter
dgs...@nu...