Debugging heap corruption

Regan Heath regan at netmail.co.nz
Mon Jul 30 02:03:15 PDT 2007


Vladimir Panteleev wrote:
> On Mon, 30 Jul 2007 05:23:18 +0300, Vladimir Panteleev
> <thecybershadow at gmail.com> wrote:
> 
>> I am currently running my program under Valgrind, waiting for some
>> results, hoping for the best. Will post updates when will have some
>> progress :)
> 
> As I expected - after two few-hour runs, the program hung once and
> segfaulted the other. In the second case, the segfault happened when
> the GC stumbled on an invalid pointer, which was there, no doubt, due
> to heap corruption. I think I'll give modding Phobos's GC another
> shot (and perhaps take a look at the warnings Valgrind spits out
> about the GC referencing uninitialized memory).

One method for finding heap corruption is to write custom memory
allocation, reallocation and free routines.

In the allocator you allocate extra memory before and after the block 
you actually return, you initialise these padding blocks to some known 
pattern and when it comes time to reallocate or free the memory you 
verify the padding is intact and has not been modified.

This allows you to figure out which piece of memory has been corrupted 
and how (overrun etc).

I used to use this to check I wasn't leaking any memory also but with a 
GC that's no longer important.

I'm not sure whether D allows you to define global custom allocators, 
anyone?  Or perhaps Tango has that capability?

Regan



More information about the Digitalmars-d mailing list