Speicherproblem mit Objekten in DLL

[himitsu]

Wird Shared Memory verwendet?

Erstellen, Verwenden und Freigeben im selben Modul (EXE/DLL) oder wird da etwas zwischen EXE und DLL übergeben?

[BastiFantasti]

Ja SharedMem habe ich als erste Unit in den Uses der DPR mit drin (habe es auch ohne versucht)

Der Aufruf des Objekts ist wie folgt:

- dpr Datei beinhaltet die eigentlich Unit (mit Form)
- die "Unit mit Form" wird in einem TThread.execute gestartet bzw. mit CreateForm erzeugt
- die TThread.execute Ereignis wird laut Breakpoint nur einmalig durchlaufen
- in der "Unit mit Form" wird das Objekt in einer Funktion (Abarbeitung der Anfrage von ausserhalb der DLL instanziert, verwendet und wieder freigegeben)
- Das eigentliche Objekt steckt in seiner eigenen Unit, die die ganze Klasse enthält


- von der aufrufenden Anwendug wird ein Record an die DLL übergeben.
Der Record ist eine definierte Schnittstelle der aufrufenden Anwendug.
Es handelt sich um eine Integration in einen FTP Server, der die relevanten Daten an die DLL übergibt (FTP Benutzernamen, übertragene Datei, Operation, ...)
Immer wenn eine Datei übertragen wird, wird der Inhalt dem FTP Benutzer zugeordnet und der Inhalt der Datei mit der eigentlichen Anforderung ausgewertet.

Ich hoffe ich habe das verständlich aufgelistet

[jaenicke]

Die entscheidende Frage ist doch:
Wird der Destruktor in der DLL durchlaufen, sprich kommst du an einem Haltepunkt darin an?

Wenn Hostanwendung und DLL in der gleichen Projektgruppe liegen, solltest du direkt in der DLL debuggen können, sofern Debuginformationen und ggf. externe Debugsymbole aktiviert sind. Ansonsten kannst du die Hostanwendung auch als solche im DLL-Projekt eintragen und dieses dann starten.

Wichtig ist dabei, dass Speicher nicht unbedingt sofort wieder freigegeben wird. Zur Optimierung behält der Speichermanager den Speicher ggf. auch, um ihn später erneut zu verwenden. Deshalb kann man am Speicherverbrauch nicht unmittelbar sehen, ob der Speicher freigegeben wird.

In den Beispielen zu FastMM4 z.B. ist ein Beispiel enthalten, wie man die Speicherbelegung direkt sehen kann. Außerdem zeigt es Speicherlecks beim Beenden an. Das funktioniert in einfacher Form auch mit ReportMemoryLeaksOnShutdown, das in Delphi bereits integriert ist.

Bezüglich des Records:
Ich persönlich würde die Klasse in der DLL (oder eine zusätzliche Verwaltungsklasse) einfach mit Implementierung eines Interfaces implementieren, das dann von der Hostanwendung abgerufen werden kann. Dann kann man die Klasse dort direkt nutzen.
Dafür kannst du z.B. mein AppCentral Projekt nutzen:
https://www.delphipraxis.net/213199-...ng-dlls-c.html

[BastiFantasti]

Die DLL wird zu dem Zeitpunkt nicht beendet.
D.h. der Destruktor wird auch noch nicht durchlaufen.
Die DLL läuft in der Anwendung über mehrere Tage/Wochen.

FastMM4 habe ich in die DLL eingehängt und bekomme beim Beendern aber nur ein Speicherleck von ein paar kB.
Das Problem ist aber, dass obwohl das Objekt zur Laufzeit instanziert und Freigegeben wird, die DLL den Speicher immer aufaddiert und nichts mehr davon freigibt.
D.h. nach ein paar Iterationen belegt die DLL ihre vollen 2GB Speicher.

Wie gesagt funktionieren die gleichen Aufrufe zum Erstellen und Freigeben des Objekts in einer Testanbwendung wie erwartet.

[TiGü]

Fang mal von vorne an und mache dir ein ganz kleines Konsolenprogramm (kein VCL!) und rufe von dort die exportierte DLL-Funktion auf.

[BastiFantasti]

Ja ich glaube da werde ich nicht drum rum kommen...
Ich werde berichten

[Sinspin]

Du übergibst der Dll Funktion den String? Um Spass mit langen Strings zu vermeiden verwende ich für die Kommunikation mit Dll's Named Pipes oder gleich einen Netzwerk Socket.

[jaenicke]

Zitat von BastiFantasti:

Die DLL wird zu dem Zeitpunkt nicht beendet.
D.h. der Destruktor wird auch noch nicht durchlaufen.

Wenn kein Destruktor durchlaufen wird, wird auch nichts freigegeben. Du hast eingangs doch aber genau das beschrieben:

Zitat von BastiFantasti:

Wenn ich nun die gleiche Klasse in eine Win32 dll verfrachte und das Objekt dort instanziere und wieder freigebe, steigt der Speicherverbrauch bei jedem Aufruf aufs neue an. D.h. mit jedem neuen Durchlauf des Konstruktors schnappt sich die Anwendung zusätzliche 2-5MB.

Darum kann ich dir nicht mehr folgen, wenn du plötzlich sagst, dass gar kein Destruktor durchlaufen wird. Wo wird denn nun Speicher reserviert und wo soll er freigegeben werden? Egal, ob da nun ein Destruktor involviert ist oder du manuell FreeMem aufrufst, kannst du doch dort einen Haltepunkt setzen, um zu prüfen, ob die Freigabe durchgeführt wird.

Zitat von Sinspin:

Du übergibst der Dll Funktion den String? Um Spass mit langen Strings zu vermeiden verwende ich für die Kommunikation mit Dll's Named Pipes oder gleich einen Netzwerk Socket.

Wozu der Aufwand? WideStrings können z.B. Strings mit bis zu ca. 2^30 Zeichen enthalten. Und wenn du dann noch ein Interface verwendest, hast du eine schöne Schnittstelle.

[BastiFantasti]

Oh, das war ein Missverständnis.
Der Destruktor der Klasse, der das Objekt freigibt wird natürlich durchlaufen.
Nur die DLL wird nicht freigegeben (kein PROCESS_DETACH)

Also Objekt auf (create) - verwenden - Objekt zu (freeandnil)
Der Klassendestruktor wird auch durchlaufen und die enthaltenen TList Objekte werden korrekt freigegeben.

Ich habe jetzt noch etwas weiter recherchiert und habe gesehen, dass es mit der Objektdeserialisierung zusammenhängen muss.
FastMM4 zeigt mir unzählige Elemente an die noch offen sind, wenn die Anwendung beendet wird (obwohl die Objekte freigegeben sind).

Erschwerend kommt hinzu, dass diese Aufrufe innerhalb eines TThreads erfolgen. Eventuell gibt es auch hier Probleme mit der Speicherverwaltung / Freigabe.

Ich habe eine Test DLL gebaut, wo nur eine Funktion exportiert wird, die genau die gleiche Funktionalität abbildet wie oben beschrieben (Objekt auf, verwenden, zu)

Da tritt dieses Speicherleck nicht auf.

[Sinspin]

Das leakt auch wenn nur in der Exe aufgerufen? Wenn nicht, würde mich wundern wenn ein anderes Verhalten für Dll implementiert worden wäre. (wie auch immer das gehen sollte)

Zitat von jaenicke:

Zitat von Sinspin:

Du übergibst der Dll Funktion den String? Um Spass mit langen Strings zu vermeiden verwende ich für die Kommunikation mit Dll's Named Pipes oder gleich einen Netzwerk Socket.

Wozu der Aufwand? WideStrings können z.B. Strings mit bis zu ca. 2^30 Zeichen enthalten. Und wenn du dann noch ein Interface verwendest, hast du eine schöne Schnittstelle.

Ja, das musst Du schon beantworten. Wozu soll ich mir den Aufwand machen und mich mit Interfaces belasten?
Ich kann mit einem Modul alle beliebigen Daten übertragen die ich will. Eine serialisierbare Memtable kümmert sich intern um alles nötige zur Datenverwaltung. Einmal eingebunden kann ich mit allen Modulen kommunizieren. Egal ob auf einem Rechner, zwischen Diensten, zwischen Rechnern, übers Internet. Selbst broadcast.