TDAESQLCommand weak reference

Data Abstract
1

latest release introduces a [weak] ref for fconn
this results in an error using FastMM since InstHashMap.Finalize comes after Fastmm is uninstalled but it is still trapped by it resulting in a crash

image
image.png1440×71 4.82 KB

4

I’ll log an issue to review this. IIRC the weak modifier has been introduced to counter some ARC issues on Linux, so we cannot just remove it.

5

Thanks, logged as bugs://81601

6

workaround is to set fastmm to not report mem operations after fastmm is destroyed…

7

bugs://81601 got closed with status nochangereq.

8

you are right. this is fastmm4 issue that is unloaded before InstHashMap is cleared.

9

right but the cause is the weak ref that somehow isn’t destroyed before the finalize of the system unit?

10

in this specific case:

  TDAESQLCommand = class(TDAEngineBaseObject, IDASQLCommand, IDAMustSetParams, IDANativeObject_StreamerSupport, IDASQLCommandNativeObject)
  private
    {$IFDEF DELPHIXE3UP}[Weak]{$ENDIF}fconn: IDAConnection;

we clear this variable:

destructor TDAESQLCommand.Destroy;
begin
...
  fconn := nil;

but seems, that InstHashMap still contains some data that [weak] attribute was used and fastmm was able to detect it.