Heap overruns

[Shachar Shemesh]

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.

Whenever you free a buffer, you check the hot zones. If they have 
changed, the buffer you are freeing now has been overwritten. This gives 
an excellent debugging tool, as it points right at the offending code.

I am going to try and find my overrun buffer the conventional way. If 
that doesn't work, I'll implement the system described above. Who knows 
how many overflows are out there that do not crash the system, and go 
about undetected?

                        Shachar