TDAESQLCommand weak reference


(marcantheunis) #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

(antonk) #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.

(RemObjects) #5

Thanks, logged as bugs://81601

(marcantheunis) #6

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

(RemObjects) #7

bugs://81601 got closed with status nochangereq.

(EvgenyK) #8

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

(marcantheunis) #9

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

(EvgenyK) #10

in this specific case:

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

we clear this variable:

destructor TDAESQLCommand.Destroy;
  fconn := nil;

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