search

pleriche / FastMM5

FastMM is a fast replacement memory manager for Embarcadero Delphi applications that scales well across multiple threads and CPU cores, is not prone to memory fragmentation, and supports shared memory without the use of external .DLL files.
283 stars 73 forks source link

FASTMM_FullDebugMode now forces the DLL to be there #26

Closed obones closed 2 years ago

obones commented 2 years ago

Using FastMM4, it was possible to have this set of defines:

{$define FASTMM_FullDebugMode}
{$define LoadDebugDLLDynamically}
{$define DoNotInstallIfDLLMissing}

When we moved to FastMM5, I translated those defines to this code:

  {$ifdef FASTMM_FullDebugMode}
    //{$define LoadDebugDLLDynamically}
    if FastMM_LoadDebugSupportLibrary then
    begin
      //{$define FullDebugMode}
      FastMM_EnterDebugMode;
    end
    else
    begin
      //{$define DoNotInstallIfDLLMissing} --> nothing to do, we fail silently
    end;
  {$endif}

This was working just fine about a year ago, but now that I have updated to latest code last week, my exe can no longer run if the DLL is missing. I believe this comes from these lines: https://github.com/pleriche/FastMM5/blob/c4398de72378822261d460b153ae6d2047548a5b/FastMM5.pas#L171-L174

I know if feels a bit strange to build with FullDebugMode activated and yet not ship the associated DLL, but this may happen in some cases around here. With the current code, we can no longer support this situation, and I'm wondering if it would be possible to bring back support for this case, even if it requires a new option for us to use.

pleriche commented 2 years ago

Hi Olivier,

I have added back support for the LoadDebugDLLDynamically define. If defined it will not force the static dependency on FastMM_FullDebugMode.

The reason why I made the dependency static, is because of the high number of support requests that I received with the dynamic loading mechanism. The root of the issue is that Windows is unable to reliably untangle the dependency chain between modules when you load DLLs dynamically during application startup. If you use runtime packages or share the memory manager with other DLLs, then what would often happen is that Windows would unload FastMM_FullDebugMode prematurely during application shutdown, and then FastMM would crash while generating the leak report, because it could not convert stack traces to source information.

The default behaviour with FastMM_FullDebugMode enabled remains a static dependency, but you can now override that with a define as you could in v4.

Best regards, Pierre

obones commented 2 years ago

Hello,

I totally understand the rationale behind your decision, and I appreciate that you took the time to bring back this behavior. It is perfectly fine by me that this is not active by default.