Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[FastMM] ScanMemoryPoolForCorruptions

27 views
Skip to first unread message

Francois Piette [ICS & Midware]

unread,
Jul 30, 2008, 10:10:45 AM7/30/08
to
[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.

--
francoi...@overbyte.be
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be


Pierre le Riche

unread,
Jul 31, 2008, 6:27:39 AM7/31/08
to
> 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 ?

Corruptions should be logged to file with stack traces and other
information.


> I think that using FullDebugModeScanMemoryPoolBeforeEveryOperation will have
> a huge impact on performance.

It is very slow, especially if you have a large number of live pointers.


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

You'll have the stack trace of when the block was allocated. That should
help a lot.

Regards,
Pierre

0 new messages