Heap overruns

[Marcus Meissner]

> 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.

Such a thing is not really implemented yet.

There is a freeware tool called 'valgrind' which might be instrumentable,
but I do not think it can cope with wines very own memory management yet.

You could add assert(HeapValidate(heap,0,NULL))); around critical pieces
of code, to call the heap checking more often. (replace heap by
GetProcessHeap(), or whatever heap you use.)

Additionaly you could careful reread and reaudit your code (even in diff form)
;)

Ciao, Marcus