Heap overruns

[Huw D M Davies]

On Sun, Sep 01, 2002 at 11:33:55PM +0300, Shachar Shemesh wrote:
> Marcus Meissner wrote:
> 
> >On Sun, Sep 01, 2002 at 12:17:38PM +0300, Shachar Shemesh wrote:
> >  
> >
> >>Hi list,
> >>
> >>I am currently having some problems with a change I am working on, that 
> >>result in heap corruption as a result of buffer overrun. I was wondering 
> >>whether there was any builtin debug options to detect and help fix these 
> >>things.
> >>
> >>If there aren't, I am perfectly willing to sidetrack a little and write 
> >>them. Please let me know.
> >>    
> >>
> >
> >If you run with -debugmsg +heap it will check the heaps at every access
> >for corruption.
> >
> >Ciao, Marcus
> >  
> >
> Thanks, but this is not what I meant.
> 
> Currently, when a buffer overruns, the free pointers right after get 
> corrupted, and when the next piece of block is allocated, the machine 
> will crash. This will tell me approximetly where the buffer overrun, but 
> is, generally speaking, too late. Enabling the debug messages detects 
> the error at the same place (i.e. - too late).
> 
> What I am talking about is a compile time (or run time, no reason why 
> not) option that will add "hot zone" areas before and after each heap 
> allocated buffer. These zones should be:
> A. Large enough so that the overrun doesn't reach the heap managment 
> structures themselves. This means that the program can keep on running 
> despite having the buffer overflow.
> B. Identifiable, so that we know if a buffer has overwritten it.

No, as Marcus says, enabling +heap debugging forces the entire heap to
be checked for consistency on every HeapAlloc/Free/ReAlloc .  So if
you overwrite a block you'll get an error the next time you call a
heap function (on the same heap) and not only when the system tries
the alloc the next block.  So, if you see heap corruption this way,
you can assume that it occured somewhere between this point and the
last time you called a heap function.

Huw.