TTask.Run(...) in DLLs

[BerndS]

Mir ist gerade aufgefallen, dass die Verwendung von TTask.Run ein Problem mit der Speicherfreigabe hat, wenn man das in einer DLL verwendet.

Zitat:

An unexpected memory leak has occurred. The unexpected small block leaks are:

1 - 12 bytes: TObject x 4
21 - 28 bytes: TLightweightEvent x 2
29 - 36 bytes: TWorkStealingQueue<System.Threading.TThreadPool.IT hreadPoolWorkItem> x 2
45 - 52 bytes: TThreadPool.TThreadPoolMonitor x 1
61 - 68 bytes: TThreadPool.TQueueWorkerThread x 2, Unknown x 4
69 - 76 bytes: UnicodeString x 1
133 - 140 bytes: Unknown x 2
173 - 188 bytes: UnicodeString x 1

In der System.Threading wird für den Fall, das es eine DLL ist, die DLLShutdownProc aus der Unit System entsprechend angepasst.
Beim Entladen der Dll sollte dann DLLShutdown aufgerufen werden.

Aber DLLShutdown wird anscheinend gar nicht aufgerufen.
In der Unit hat diese Teil keine blauen Pünktchen.

Kann es sein, dass das vergessen wurde?
Mit XE7 gibt es übrigens kein Speicherproblem.

[WiPhi]

Hi,

Zitat:

Zitat von BerndS (Beitrag 1519658)

Aber DLLShutdown wird anscheinend gar nicht aufgerufen.
In der Unit hat diese Teil keine blauen Pünktchen.

Hast du einmal testweise eine eigene procedure an DLLShutdown zugewiesen und geschaut ob die ausgeführt wird?

[BerndS]

@WiPhi
Ja, das habe ich mal getestet indem ich DLLShutdown im finalization hinzugefügt habe. Das wurde dann auch ausgeführt, hat aber das Speicherleck nicht beseitigt.
Das Freigeben erfolgt im ShutdownThreadPool in der System.Threading auch im class destructor TThreadPool.Destroy.
Damit ist das RegisterDLLShutdown im initialization eigentlich überflüssig.

Ich benötigte das TTask.Run nur gelegentlich zum Test um Tastaureingaben per TSendInputHelper zu senden und werde das nicht weiter untersuchen.

[Uwe Raabe]

Kann es sein, dass die Überprüfung einfach nur vor dem Ausführen des Codes erfolgt?

[WiPhi]

Zitat:

Zitat von Uwe Raabe (Beitrag 1519677)

Kann es sein, dass die Überprüfung einfach nur vor dem Ausführen des Codes erfolgt?

Wäre eben auch meine Vermutung gewesen. Wenn das DLLShutdown ohne Probleme aufgerufen wird, wird der ThreadPool auch freigegeben.

[BerndS]

Ich habe mir nun doch die Mühe gemacht und den Ablauf mal genauer debugt.

Ich habe mal Haltepunkte in

• constructor TLightweightEvent.Create
  und
  destructor TLightweightEvent.Destroy

gesetzt.

Ohne TTask.Run wird Create und Destroy wird jeweils einmal aufgerufen.
Beim 1. TTask.Run wird
TLightweightEvent.Create 3 mal
und
destructor TLightweightEvent.Destroy nur einmal aufgerufen.

Beim 2. TTask.Run

TLightweightEvent.Create einmal
und
destructor TLightweightEvent.Destroy einmal

Die Ursache habe ich inzwischen auch gefunden.

Im destructor TThreadPool.Destroy ist IsDLLDetaching = True und in diesem Zweig wurde die Freigabe der Items vom FThreads.LockList vergessen.

Wer 11.3 und die Quellen hat kann das in System.Threading.pas Zeile 2986 bis 2998 erkennen. Im else Zweig wird eine lokale Liste LocalFreeList aufgebaut und diese zu Freigeben verwendet (Zeile 3014 bin 3034). Die Feigabe erfolgt in Zeile 3027 bis 3028.

Man sollte das als Bugreport anlegen, aber dazu ist mein Englisch etwas mau.