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