This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Trying to spot memory corruption with core dump
On Tue, Jul 28, 2009 at 12:11 AM, Pavel Shevaev<pacha.shevaev@gmail.com> wrote:
>> On Linux/ix86 and x86_64, nothing beats Valgrind (for finding heap corruption).
>
> Oh, forgot to mention this on the very first post. I'm using linux
> x86_64 and I'm aware of Valgrind and I even tried it....the problem is
> it doesn't detect any memory corruption at all and what's even more
> amazing my application doesn't seg.fault under Valgrind even after
> running the whole day :(
With typical VG slow-downs (50x to 100x), you need to run it longer: 3
hours without VG => 50*3/24.0 == 1 week under VG.
> I think it's because Valgrind slows down the
> application considerably and some how the rare edge case when memory
> corruption occurs simply doesn't happen.
Is the application multithreaded?
Does it process a "random" event source?
VG could change timing and make bugs hide; that's not unheard of.
You could try setting MALLOC_CHECK_=2 in the environment (see 'info
libc'), or linking the application with '-lmcheck'.
Finally, does your application handle async signals?
If so, does signal handler call anything async-signal unsafe? That is
one common source of "random" heap corruption.
Cheers,
--
Paul Pluzhnikov