Heap overruns

[Shachar Shemesh]

Marcus Meissner wrote:

>Such a thing is not really implemented yet.
>
Does anyone have any objections to me having a go at implementing it 
(perhaps at some time in the future)?

>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.
>
It has a whole bunch of other limitations that do not look promising. 
Bad replacing stacks, bad own memory managment support (i.e. - we have 
to teach it how Windows allocates memory), no good support of threads. 
It seems to me like there is a LOT of porting work to do.

My suggestion, while nowhere near as powerful as that, is simple and 
with low overhead.

>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.)
>
I have found the specific cause of my corruption. I am talking about a 
"next time" tool, as well as an auditing tool (the most dangarous 
overruns are those that do not crash the program).

I was also not asking anyone to implement this. Just asking whether 
anything like that was already implemented, and whether there was any 
objections to me having a go at implementing it if not.

                Shachar