FastMM in full debug mode

[Alan Garny]

I was wondering whether someone has come across the whole system freezing
when using FastMM in full debug mode. It works all fine until the moment I
shut my application, at which point my whole system simply freezes and
unless I do hard reset, it will take forever (15 minutes last time) to get
back to normal (after closing the culprit via the Windows task manager).

Hmm... I am not quite sure about how to tackle this. Note that it works fine
in 'release' mode and that according to MemCheck I don't have any leak (this
being said I know that it doesn't report some memory leaks, such as those in
the initialisation/finalisation sections).

I would like to get rid of MemCheck and only use FastMM if at all possible
(no point in having two memory managers - though never used together! -,
while one can do everything I need).

Well, I guess I will have to try using FastMM in full debug mode in a
simpler project with some of my project's characteristics to see how it
behaves...

Cheers, Alan.

[Pierre le Riche]

Hi Alan,

> when using FastMM in full debug mode. It works all fine until the moment I
> shut my application, at which point my whole system simply freezes and
> unless I do hard reset, it will take forever (15 minutes last time) to get

It is possible that it is busy generating a very large leak/error report. Is
there a lot of hard disk activity? Perhaps you can switch off the
LogErrorsToFile and perhaps also the RawStackTraces options and see if it
makes a difference.

It is also possible that the application may just have caused a lot of disk
swapping and that this is causing the very slow shutdown (although 15
minutes seem too long for this). FullDebugMode never releases memory back to
the OS (with the exception of large blocks) and never combines adjacent free
blocks, so programs do tend to use a lot more memory.

Regards,
Pierre

[Alan Garny]

"Pierre le Riche" <pler...@hotmail.com> wrote in message
news:4399...@newsgroups.borland.com...

>> when using FastMM in full debug mode. It works all fine until the moment
>> I
>> shut my application, at which point my whole system simply freezes and
>> unless I do hard reset, it will take forever (15 minutes last time) to
>> get
> It is possible that it is busy generating a very large leak/error report.
> Is
> there a lot of hard disk activity? Perhaps you can switch off the
> LogErrorsToFile and perhaps also the RawStackTraces options and see if it
> makes a difference.

Thanks for these Pierre. Yesterday night, I completed the migration of my
project to D2006, so I made quite a few changes (the last ones being to
inline things wherever possible). Why am I mentioning this? Well, because
now it works fine, i.e. it doesn't hang up for ever. I initially undefined
both LogErrorsToFile and RawStackTraces, and it was quick to close my
application. Then I undefined one of them at a time and again: quick to
close. Finally, I defined both of them, something that yesterday got me to
wait for ever, but this time (did it just a few minutes ago), it closed
immediately. I am kind of puzzled as to why the difference, since I didn't
modify my code as such (just added a few units here and there so that the
compiler can allow inlining for instance, included the inline keywor here
and there, etc.).

Still, the fact remains that my application seems to be having some leaks
that MemCheck didn't report before (besides the well known Indy leak - by
the way, is that leak still present in D2006? I haven't checked yet...):

5 - 12 bytes: TIdThreadSafeInteger x 1
21 - 28 bytes: TIdCriticalSection x 2

Incidentally, that is much less than with D7 from what I can recall...

Alan.

[Pierre le Riche]

Hi Alan,

> Still, the fact remains that my application seems to be having some leaks
> that MemCheck didn't report before (besides the well known Indy leak - by
> the way, is that leak still present in D2006? I haven't checked yet...):

It is. Even if the leak itself is not fixed, it should at least be
registered so the leak report doesn't show every time.

Regards,
Pierre

[Pierre le Riche]

> It is. Even if the leak itself is not fixed, it should at least be
> registered so the leak report doesn't show every time.

QC#22148

[Alan Garny]

"Pierre le Riche" <pler...@hotmail.com> wrote in message

news:439a...@newsgroups.borland.com...

Yes, indeed. I have registered them, so now they don't show up as such
anymore. Nice feature indeed! :)

Alan.