wine-devel at sun.consumer.org.il
Sun Sep 1 15:33:55 CDT 2002
Marcus Meissner wrote:
>On Sun, Sep 01, 2002 at 12:17:38PM +0300, Shachar Shemesh wrote:
>>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
>>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
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
More information about the wine-devel