Why does FREE_ON_FINAL exists?

[mdbs99]

I'm using FPC 3.1.1, Lazarus 1.9 and Indy 10 on Windows.

I got an issue very strange for me. I have no memleaks in my project, but If I add an Indy unit, eg. IdPOP3, I got 3 memleaks (I can see using heapdtrc).

First, I thought that my code was wrong, because if I open a new one and do the same (drop a component on Form) I have no memleaks. I spent 2 hours to find out that the problem is in IdStack and IdThread units.

GThreadCount := TIdThreadSafeInteger.Create;
  {$IFNDEF FREE_ON_FINAL}
    {$IFDEF REGISTER_EXPECTED_MEMORY_LEAK}
  IndyRegisterExpectedMemoryLeak(GThreadCount);
  IndyRegisterExpectedMemoryLeak(TIdThreadSafeIntegerAccess(GThreadCount).FCriticalSection);
    {$ENDIF}
  {$ENDIF}
finalization
  // This call hangs if not all threads have been properly destroyed.
  // But without this, bad threads can often have worse results. Catch 22.
//  TIdThread.WaitAllThreadsTerminated;

  {$IFDEF FREE_ON_FINAL}
  //only enable this if you know your code exits thread-clean
  FreeAndNil(GThreadCount);
  {$ENDIF}

"only enable this if you know your code exits thread-clean"
Is this make any sense?

IMHO, of course we need to enable FREE_ON_FINAL... why not?

And why do we have an *.inc in each directory with the same information?

[rlebeau]

FREE_ON_FINAL exists to deal with bad unit finalization order in some situations. Sometimes its safe to enable FREE_ON_FINAL, other times it is safer to let the objects leak instead.

In any case, the 3 leaks are known and intentional (that is why they are registered). However, IndyRegisterExpectedMemoryLeak() is not implemented for FPC by default, because its default leak detector provides no way of registering known leaks. You would have to use FastMM or MadExcept as your project's memory manager, and enable the appropriate define in IdCompilerDefines.inc.

Otherwise, you can choose to enable FREE_ON_FINAL if you want to, if you choose to accept the possible risks (might be more an issue in Delphi than FPC).

As for why there are multiple copies of IdCompilerDefines.inc in separate folders, that is for historical reasons. Old versions of FPC had issues with sharing a common .inc file across multiple projects in separate folders. Not an issue in Delphi, or in modern FPC versions. But Indy's folder structure hasn't been cleaned up yet (that is coming in Indy 11, though). Besides, the typical installation of Indy in FPC involves copying all of the source files to a single folder first, thus there would only be 1 copy of IdCompilerDefines.inc used.

[mdbs99]

@rlebeau I understood your explanation and it was documented, which is good. However, could it be an error in Indy architecture? A global variable never is a good sign... But, I don't know Indy architecture so, I might be wrong.
As you said, I cannot "register a memory leak" on heaptrc but I don't know if it is a good thing, though. I don't like to see memory leaks so... it's uncomfortable.

About installation, I've never used. First, I've tried to install from OPM but when I saw the memory leaks I've tried the use the SVN sources — what do you think is better, from SVN to get updates fast, right?
Clean such sources will be good in Indy 11.

[rlebeau]

"could it be an error in Indy architecture?" - not really, more an issue in some versions of Delphi, where units could still be accessed after they were finalized. But like I said, it is not much of an issue nowadays. And Indy 11 will be dropping support for old Delphi versions anyway, so its possible that enabling FREE_ON_FINAL could possibly become the new default at that time.

SVN is the latest, yes (with mirrors on GitHub), but OPM is not far behind the latest. The OPM author is pretty good about resyncing OPM fairly quickly after a new SVN checkin.

[mdbs99]

...more an issue in some versions of Delphi, where units could still be accessed after they were finalized.

I got it.

...so its possible that enabling FREE_ON_FINAL could possibly become the new default at that time.

I think this is a good idea.

Thanks for the tips.

[tothpaul]

Hello,

if it's a Delphi version problem, you should add a $IF CompilerVersion to define or not the FREE_ON_FINAL

[rlebeau]

I can't do that, as I don't know which specific versions are actually affected. Nor do I know if the problem is truly gone in all possible scenarios, for that matter.