Mike Hearn wrote:The issue with this approach is that you only trigger the check when releasing the block. It might well happen that the crash takes place before you free the memory. IMO, this is well suited to situations where either you have, from time to time, synchronisation points (you check the heap situation) or you check a memory block before using it (think of overloading operator-> in C++).
This is very much like a problem I am having with InstallShield.Something else that might help is an algorithm I suggested a long time ago, and which was not thought as worth the effort. Since I have not tried to run Wine with valgrind yet, I don't know whether it is or isn't.
Something, somewhere, is trashing the heap data structures, which causes
a crash some time later, often yards away from the original bug. As far
as I know, there is no good way to spot this problem, it's just C/C++
sucking.... maybe valgrind might help?
The gist of it is that you pad each and every alloc with more memory, and you fill it in with signatures. When you release the memory, you check that the signatures are ok. Tweaking the amount of extra memory can cause you to not corrupt the heap structure at some point, which will allow you reliable pin-pointing the buffer in which the overflow occures.
In this case it would help if:
- crash doesn't take place before buffer release
- you are able to identify the buffer (where it has been allocated)
- then you can set a hardware watchpoint on the buffer to know who overwrites it
tricky but doable.
IMO, running valgrind will allow you actually stop on the faulty write operation. valgrind is worth a try.
A+ -- Eric Pouech
