Shutdown and uninstall MM fail

[GoogleCodeExporter]

Compiler: Delphi XE2 + Upd3 (German version)
ScaleMM2: V2.13 SVN Rev 94

If I use the ScaleMM2 in EXE and (dynamical loaded) DLL I get an exception 
inside FreeLibraray. The order of shutdown the DLL seems to be wrong. I have 
the following order:
- EXE call FreeLibraray
- in DLL: DLL_PROCESS_DETACH - OK
- in DLL: Unit System calls "procedure FinalizeUnits;" - OK
  - FinalizeUnits call: unit ScaleMM2->finalization->ScaleMMUninstall;
  - FinalizeUnits call at last: unit System->finalization;
  - System->finalization call:
    {$IFDEF MSWINDOWS}
      FinalizeLocaleDate;
      if PreferredLanguagesOverride <> nil then
          FreeMem(PreferredLanguagesOverride);  -> EXCEPTION here!!!
    {Uninitialize the default memory manager, and free all memory allocated by this memory manager.}
      FinalizeMemoryManager;
    {$ENDIF MSWINDOWS}

I thing ScaleMM should shutdown inside FinalizeMemoryManager call.

Original issue reported on code.google.com by mxxa2a...@gmail.com on 14 May 2012 at 1:53

[GoogleCodeExporter]

Is ShareMM2 the first unit in the dll?

If yes: can you make a small test app to reproduce?
I tried a small test in D2010 which works fine..

Original comment by andre.mussche on 16 May 2012 at 10:13

[GoogleCodeExporter]

The problem is not only inside DLLs. It's also in EXE available:

You need to call ... (e.g. in constructor of MainForm in EXE)
SetLocaleOverride('DE');
... and the close the program.

If the module set a language then in system.pas the line ...
if PreferredLanguagesOverride <> nil then FreeMem(PreferredLanguagesOverride);
... will be called.

Workaround:
I disable in ScaleMM2.pas the last line ...
finalization
//ScaleMMUninstall;
... so that the MM is already online to free the memory.

ScaleMM should only uninstall if system calls FinalizeMemoryManager!

Original comment by mxxa2a...@gmail.com on 16 May 2012 at 2:52

[GoogleCodeExporter]

This is new bug in XE2! Also the latest FastMM4 gives errors this way.
There are at least 2 QC's for this issue:
http://qc.embarcadero.com/wc/qcmain.aspx?d=105136
http://qc.embarcadero.com/wc/qcmain.aspx?d=94113
So added a check if XE2 or newer :(
Anyway, thanks for reporting!

Original comment by andre.mussche on 16 May 2012 at 6:48

• Changed state: Fixed

[GoogleCodeExporter]

OK, I understand the problem. It's true, FastMM raise also an exception in this 
situation. 
Until Embarcadero did not present a solution for XE2 I can't use external MMs?
But I think nothing happens here :-(

I was in hope that you find a possibility to implement a workaround (maybe only 
for XE2). What happens if I remove the finalization call "ScaleMMUninstall" in 
ScaleMM2.pas? Are there any side-problems (e.g. in dll) if I do this? 
Why ScaleMM can't be uninstall inside the system-call "FinalizeMemoryManager" 
only?

My test to use ScaleMM in a production application was very sucesfully. But I 
need a proper shutdown.

The hope never dies ...

Original comment by mxxa2a...@gmail.com on 16 May 2012 at 7:23

[GoogleCodeExporter]

Well, ScaleMMUninstall is not really needed, but mainly because you install it 
in initialization so you should uninstall it in finalization :).

The only reason(?) is when ScaleMM2 is not the first unit (so some memory can 
be assigned using the old MM, like by SysUtils.pas etc).
And because it does not give AV's (there are also some sanity checks done if 
you enable scalemmdebugmode in options.inc) it should be OK.

Original comment by andre.mussche on 16 May 2012 at 8:10

[GoogleCodeExporter]

Maybe this is a workaround in ScaleMM2.pas:

initialization
  ScaleMMInstall;
  ExitProcessProc:=ScaleMMUninstall;  //Use ExitProcessProc to call ScaleMMUninstall 

finalization
//  ScaleMMUninstall;

What do you think??

Original comment by mxxa2a...@gmail.com on 21 May 2012 at 11:15

[GoogleCodeExporter]

Good idea! Fixed and tested, seems to work in D2010 and XE2

Original comment by andre.mussche on 21 May 2012 at 12:03