Bug in the heap management code?

[Eric Pouech]

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