Re: Trying to spot memory corruption with core dump

[Pavel Shevaev <pacha.shevaev@gmail.com>]

> 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