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