Bug in the heap management code?
pouech-eric at wanadoo.fr
Thu Sep 18 12:31:28 CDT 2003
Shachar Shemesh wrote:
> Mike Hearn wrote:
>> This is very much like a problem I am having with InstallShield.
>> 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?
> 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.
> 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
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++).
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
tricky but doable.
IMO, running valgrind will allow you actually stop on the faulty write
operation. valgrind is worth a try.
More information about the wine-devel