Unit finalization order for application, compiled with run-time packages?

Question

I need to execute my code after finalization of SysUtils unit.

I've placed my code in separate unit and included it first in uses clause of dpr-file, like this:

project Project1;

uses
  MyUnit,    // <- my separate unit
  SysUtils,
  Classes,
  SomeOtherUnits;

procedure Test;
begin
  //
end;

begin
  SetProc(Test);
end.

MyUnit looks like this:

unit MyUnit;

interface

procedure SetProc(AProc: TProcedure);

implementation

var
  Test: TProcedure;

procedure SetProc(AProc: TProcedure);
begin
  Test := AProc;
end;

initialization

finalization
  Test;
end.

Note that MyUnit doesn't have any uses.

This is usual Windows exe, no console, without forms and compiled with default run-time packages. MyUnit is not part of any package (but I've tried to use it from package too).

I expect that finalization section of MyUnit will be executed after finalization section of SysUtils. This is what Delphi's help tells me.

However, this is not always the case.

I have 2 test apps, which differs a bit by code in Test routine/dpr-file and units, listed in uses. MyUnit, however, is listed first in all cases.

One application is run as expected: Halt0 -> FinalizeUnits -> ...other units... -> SysUtils's finalization -> MyUnit's finalization -> ...other units...

But the second is not. MyUnit's finalization is invoked before SysUtils's finalization. The actual call chain looks like this: Halt0 -> FinalizeUnits -> ...other units... -> SysUtils's finalization (skipped) -> MyUnit's finalization -> ...other units... -> SysUtils's finalization (executed)

Both projects have very similar settings. I tried a lot to remove/minimize their differences, but I still do not see a reason for this behaviour.

I've tried to debug this and found out that: it seems that every unit have some kind of reference counting. And it seems that InitTable contains multiply references to the same unit. When SysUtils's finalization section is called first time - it change reference counter and do nothing. Then MyUnit's finalization is executed. And then SysUtils is called again, but this time ref-count reaches zero and finalization section is executed:

Finalization: // SysUtils' finalization
5003B3F0 55               push ebp          // here and below is some form of stub
5003B3F1 8BEC             mov ebp,esp
5003B3F3 33C0             xor eax,eax
5003B3F5 55               push ebp
5003B3F6 688EB50350       push $5003b58e
5003B3FB 64FF30           push dword ptr fs:[eax]
5003B3FE 648920           mov fs:[eax],esp
5003B401 FF05DCAD1150     inc dword ptr [$5011addc] // here: some sort of reference counter
5003B407 0F8573010000     jnz $5003b580     // <- this jump skips execution of finalization for first call
5003B40D B8CC4D0350       mov eax,$50034dcc // here and below is actual SysUtils' finalization section
...

Can anyone can shred light on this issue? Am I missing something?

Gorlovka

Answer 1

I was able to find a reason and I feel myself a bit stupid now :)

My second test application have a static reference to DLL, which was compiled with RTL.bpl (it's empty, except for references to SysUtils and having 1 simple routine). So, since DLL is statically linked, it is initialized before any code from exe have chances to run.

That's it:

DLL's System -> DLL's SysUtils -> exe's System (skipped) -> MyUnit -> exe's SysUtils (skipped) -> etc

Finalizations are in reverse order, leading to execution of MyUnit before SysUtils.

Solution: require to include MyUnit first in all projects.

(oh, how I wish to have a time-machine to travel back in time and force somebody to add OnBeforeMMShutdown event :D )

Gorlovka

Answer 2

Units are finalized in reverse order of initialization. The order of initialization is determined by a non-cyclic (i.e. never descends into an already-visited unit) post-order traversal of the unit uses graph, starting with the main uses clause (in the program or library). SysInit is normally the first unit to be initialized, followed by System.

Dynamic loading of packages complicates things, because the main EXE or DLL gets to specify the order of initialization of the units used by the main image. So when a package is dynamically loaded, it will run what it thinks should be the initialization order, but units already initialized will be skipped; when the package is dynamically unloaded, this happens in reverse.

The general rules:

• lower-level things should be initialized before higher-level things
• finalization should be in reverse order of initialization

These rules almost always make sense. Higher-level units' initializations often rely on services provided by lower-level units. For example, without SysUtils, there is no exception support in Delphi. Reverse order finalization makes sense for the same reason: high-level finalizations rely on services provided by lower-level units, so they must run before the lower-level units' finalizations.

All that said, with respect to your problem, it sounds like there may be a bug somewhere in the compiler or RTL, if what you say is true: that the main EXE uses MyUnit first, and MyUnit uses no other units in its interface or implementation, and there's no funny business going on with dynamically loaded packages. All I can suggest is to keep paring down the project with the odd behaviour until you have a minimal reproducing sample; at that point, it should be clear exactly what is causing the problem.

Oxa

All packages are static linked and there is no dynamic loading - that's for sure. Thanks for the answer, but I was afraid of that :( I hoped that somebody can give few hints to look for specific things, cause I don't know where to look else. I'll try few more times... – Gorlovka

Answer 3

You're not missing anything. That's exactly what's happening.

When your program loads a package, it will initialize all the units used in that package. When it unloads the package, it has to finalize all the units. But finalization often involves freeing variables. Remember that double-frees are a Bad Thing, especially if they happen during finalization when certain exception-handling features might have been unloaded, making debugging very difficult. So it puts a reference counter on the unit initializations so that they don't get finalized until everything that was using them is done with them.

Is there any particular reason why your MyUnit needs to finalize after SysUtils?

Skyrocket

> Is there any particular reason why your MyUnit needs to finalize after SysUtils? Yep. It's mem-leaking checks. – Gorlovka

@Alexander: Is it doing something special that you can't get with FastMM in FullDebugMode? – Skyrocket

> Is it doing something special that you can't get with FastMM in FullDebugMode? That is not the question, which I'm asking, so let's put it aside. FastMM didn't work in my second app exactly for the same reason: it's called a way too early. – Gorlovka

(as preemptive comment: I'm not trying to use FastMM at all, so don't suggest AQTime or something - I just tried to use FastMM as additional check, if I'm totally stupid or not; the original problem is unexpected execution order; I'm trying to understand what is it and see if I can control it) – Gorlovka

Answer 4

I am not sure but isn't there still the good old ExitProc global variable of Turbo/BorlandPascal fame? If yes, this could solve your problem.

Micrometeorology

Yes, it is. Unfortunately, this routine is called before calling any finalization section. So, this one is too early. There is also ExitProcess event, but it's called right before process termination - a way too late. (I do not write memory manager - only install a filter; so it is important to me to execute my code before System's finalization when default memory manager may free all memory) Heck, I'm thinking about installing hook on System's finalization :( Just kidding. – Gorlovka

@Alexander: Maybe a hook on SysUtils finalization isn't such a bad idea if you can't get it solved otherwise. – Micrometeorology