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
> 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.
Unfortunately, I can't afford it :(
> Is the application multithreaded?
Yes. And yes, I tried using helgrind as well and it discovered nothing...
> Does it process a "random" event source?
Well, it uses async handlers of boost::asio which in my case used as a
nice demultiplexing wrapper around epoll
> 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'.
Thanks for the MALLOC_CHECK_ tip! I'm going to stress test my app using it...
> 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.
Oh, no, nothing like that is used.
P.S. thanks again for being helpful, I've been trying to spot this
memory corruption for a week, I think I'm gradually going mad, so,
_any_ help is highly appreciated
--
Best regards, Pavel