[Followup from the subject "Issue with FastFreeMem (FastMM V4.70)"]
My application est now running with FastMM 4.84 in full debug mode and
madExcept 3.0e, compiled with D7.
The code execute ScanMemoryPoolForCorruptions very frequently (each time a
client disconnect, this happend almost everysecond). After 20 minutes of
run, ScanMemoryPoolForCorruptions detect a corruption. But the program
continue to work and on the next call, ScanMemoryPoolForCorruptions reports
no more corruption. MadExcept don't detect anything. The application
continue to work perfectly (now for more than 4 hours and still runs
perfectly).
My question is: Once ScanMemoryPoolForCorruptions detect a corruption, how
to know which kind of corruption it is, and even better, how to know from
where was the corrupted memory has been allocated and corrupted ?
I think that using FullDebugModeScanMemoryPoolBeforeEveryOperation will have
a huge impact on performance. Would it helps to turn it on ? I will know
when it is corrupted, right after corruption but I'll have no idea what was
the source of the corruption.
Any help appreciated.
--
francois.piette@overbyte.be
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be
