String in dll aufräumen

[hanspeter]

Hallo,

kann es sein, das Delphi in einer Dll Strings beim Beenden nicht korrekt aufräumt?
Beim Beenden einer Dll werden grundsätzlich Speicherleak angezeigt.
Dabei sind manchmal bis 50 Unicodestrings und mehrere 20 bis 40 byte große "unknow" Einträge.
Da die dll ohnehin entladen wird, ist das zwar egal. Es sieht aber zumindest
unschön aus.

Gruß
Peter

[himitsu]

Zitat:

Zitat von hanspeter

kann es sein, das Delphi in einer Dll Strings beim Beenden nicht korrekt aufräumt?

eigentlich nicht

Zitat:

Zitat von hanspeter

Da die dll ohnehin entladen wird, ist das zwar egal. Es sieht aber zumindest
unschön aus.

Ist es nicht.
Blos weil die DLL entladen wird, würde dennoch der Speicher erst beim Beenden der ganzen Anwengung freigegeben.

Aber zum Glück gibt FastMM den gemeldeten und in ihm noch nicht freigegebenen Speicher, nach der Anzeigen frei.
(Speicher, welcher nicht über FastMM reserviert und nicht freigegeben wurde wird nie angezeigt ... dazu zehlen z.B. WideStrings, bei welchen an der Speicherverwaltung aka der automatischen Freigabe manipuliert wurde)


Nutzt du Strings, dynamische Array, Objekte oder Dergleichen über die DLL-Grenze hinweg, z.B. als Parameter oder Funktionsergebnis drüben in der EXE?

Wenn ja:
- sowas macht man nicht (jedenfalls nicht ohne einen SharedMM)
- tja, dann liegt es an der Referenzzählung des Strings und in der EXE, zu diesem Zeitpunkt, noch existierender Referenzen.

Auch noch nicht freigegebene Intefaces könnten hier Probleme bereiten.

[sirius]

Zitat:

Zitat von himitsu

Zitat:

Zitat von hanspeter

kann es sein, das Delphi in einer Dll Strings beim Beenden nicht korrekt aufräumt?

eigentlich nicht

Wenn ich an das hier denke, würde ich die Bedenken des TE durchaus teilen.
Habe aber grad keine Zeit nachzusehen.

[himitsu]

Das in Speicherleck in MakeObjectInstance wird nicht über den Delphi-Speichermanager erstellt und kann demnach nicht von FastMM gemeldet werden.

Dieses Speicherleck wird direkt in der prozessinternen Speicherverwaltung von Windows (über VirtualAlloc) erzeugt.

[hanspeter]

Zitat:

Zitat von himitsu

Nutzt du Strings, dynamische Array, Objekte oder Dergleichen über die DLL-Grenze hinweg, z.B. als Parameter oder Funktionsergebnis drüben in der EXE?

Wenn ja:
- sowas macht man nicht (jedenfalls nicht ohne einen SharedMM)
- tja, dann liegt es an der Referenzzählung des Strings und in der EXE, zu diesem Zeitpunkt, noch existierender Referenzen.

Ja ich nutze String und alles was "macht man nicht" aufzählt als Aufrufparameter. Das geht problemlos.
Allerdings werkelt an der Schnittstelle ein Marschaller. - (Remobjects Hydra-Plugin).
Ich schließe eine Instanz und führe anschließendexplizit ein Unload für die dll aus.
Beim Schließen des Rahmenprogramms kommen dann die Speicherleak Meldungen.
(Das Rahmenprgramm hat keine Funktionalität und stellt nur ein Panel als Container für die dll bereit.

Gruß
Peter

[sirius]

@himi, ich weis doch, dass das nicht dasselbe ist. Aber du warst dir halt spontan so sicher, dass Delphi da schon alles richtig macht. Das war nur ein Beispiel, dass Delphi eben nicht alles richtig macht.