[Erledigt] Preview Handler in VCL erzeugt MemoryLeak

[Aviator]

Hallo DPler.
Da ich mit meinem Programm sehr viele Dokumente abspeichere und danach natürlich auch wieder anzeigen lassen möchte, habe ich mir überlegt, einen Preview Handler in meinem Projekt mit einzubinden. Ich möchte also Word, Excel, PDF, ... Dateien in meinem Programm per Vorschau anzeigen.

Den Quellcode, wie das denn funktionieren sollte, habe ich von hier. Diese Unit funktioniert auch und macht auch das was es soll.

Ich habe mir zum Testen das Beispielprojekt von dieser Seite heruntergeladen und ausprobiert. Da ich bei meinem neuesten Projekt aber peinlichst darauf achte, dass ich keine Memory Leaks erzeuge, habe ich auch hier nachgeschaut, ob alles sauber wieder freigegeben wird und keine Leaks entstehen.

Also habe ich die Zeile ReportMemoryLeaksOnShutdown := True; in das Beispiel Projekt eingebunden, eine Vorschau geladen und das Programm wieder geschlossen. Ich dachte schon "na super - alles funktioniert wie es soll also kann ich es bedenkenlos benutzen". 10 Sekunden nach der Beendigung des Programms kam dann allerdings die Meldung, dass doch ein MemoryLeak erkannt wurde und das Programm sogar nicht mehr funktionieren würde. (Im TaskManager wird der Prozess auch nach der Beendigung des Programmes angezeigt. Auch wenn ich die Zeile ReportMemoryLeaksOnShutdown := True; weglasse.)

In der Meldung steht, dass eine Instanz des TStreamAdapter nicht freigegeben wurde.

Nun meine Frage: Wie bekomme ich diesen "Fehler" weg bzw. wie lässt sich das umgehen? Ich bin für jede Hilfe dankbar die ich hier bekomme.

Im Anhang noch die Fehlermeldung.

[Sir Rufo]

In Zeile 42 ist der Fehler

[himitsu]

Zitat von Sir Rufo:

In Zeile 42 ist der Fehler

Pro 7?

[Sir Rufo]

Zitat von himitsu:

Zitat von Sir Rufo:

In Zeile 42 ist der Fehler

Pro 7?

Passt gut gerade

[jaenicke]

Er hat den Quelltext doch verlinkt...

Das passiert auch mit der Demo schon. Aber ist wohl zu viel verlangt das auszuprobieren.

In dem Quelltext sind leider zwei gravierende Fehler drin. Der wichtigste ist, dass der TFileStream freigegeben wird, obwohl der TStreamAdapter mit soOwned erzeugt wird. Dadurch gibt es einen Fehler beim Freigeben (logisch) und daher rührt das Speicherleck.

Der zweite wichtige Fehler ist, dass dort der Registry-Schlüssel mit LRegistry.OpenKey(LKey, True); frecherweise einfach erzeugt wird, statt ihn nur zu versuchen zu öffnen und den Rückgabewert auszuwerten.
Richtig daher:

Delphi-Quellcode:

    if LRegistry.OpenKey(LKey, False) then
    begin
      Result := LRegistry.ReadString('');
      LRegistry.CloseKey;
    end
    else
      Result := '';

[Aviator]

Danke Jaenicke, ich versuche mal das Problem mit deinen genannten Hinweisen zu lösen.

@Sir Rufo: Bitte den Beitrag das nächste Mal ganz durchlesen und dann antworten. Danke.

[Aviator]

@Jeanicke: Habe das Problem denke ich mit deinen Stichpunkten lösen können, indem ich 1. deinen Teil mit dem Registry Code ersetzt habe und 2. im OnDestroy die Zeilen

Delphi-Quellcode:

if FFileStream<>nil then
  FFileStream.Free;

entfernt habe. Ob das allerdings so richtig ist, weiß ich nicht. Wäre nett, wenn du mir sagen könntest ob das so stimmt. Der Memory Leak kommt zumindest nicht mehr.

Ein kleines weiteres Problem (was allerdings nicht so super tragisch ist aber ich gerne gelöst hätte) ist, dass das Programm beim Beenden noch ca. 10 Sekunden lang offen bleibt. Kennt jemand den Grund dafür und wie man das möglicherweise beheben kann, oder ist es einfach so (was ich mit nicht vorstellen kann) ?

Zitat:

Das passiert auch mit der Demo schon. Aber ist wohl zu viel verlangt das auszuprobieren.

Wenn du damit mich meintest: Oben schrieb ich bereits, dass ich das Beispielprojekt geladen und getestet habe und ich auch deshalb auf den Fehler aufmerksam geworden bin.

[jaenicke]

Zitat von Aviator:

Zitat:

Das passiert auch mit der Demo schon. Aber ist wohl zu viel verlangt das auszuprobieren.

Wenn du damit mich meintest: Oben schrieb ich bereits, dass ich das Beispielprojekt geladen und getestet habe und ich auch deshalb auf den Fehler aufmerksam geworden bin.

Nein, ich meinte Sir Rufo, da ich davon ausgegangen bin, dass er den Link gesehen hatte, aber trotzdem nicht erst einmal dort nachgeschaut und ausprobiert hat. Das kommt hier in der DP in letzter Zeit leider häufiger vor, dass ähnliche Kurzbeiträge druntergehauen werden obwohl im Beitrag eigentlich alles drin ist, es nachzuvollziehen aber vielleicht 1-2 Minuten mehr erfordert hätte.
(Hauptsache Beitragszähler erhöhen?)

Zitat von Aviator:

@Jeanicke: Habe das Problem denke ich mit deinen Stichpunkten lösen können, indem ich 1. deinen Teil mit dem Registry Code ersetzt habe und 2. im OnDestroy die Zeilen

Im LoadPreviewHandler muss die Freigabe des Streams auch noch raus.

Bei mir passiert das mit der Wartezeit nicht mehr, das hatte ich anfangs aber auch. Ich glaube das liegt am eingebetten Programm. Das müsste man vielleicht noch genauer untersuchen. Da das ganze über COM läuft, vermute ich aber, dass da noch auf etwas gewartet wird.

[Aviator]

Hi und danke für die Antwort. Die Dauer des Beendens ist zwar dennoch vorhanden, aber es kommen keine Fehler (Memory Leaks) mehr. Leider kenne ich mich mit COM nicht aus und kann daher auch nicht nachvollziehen, wieso es so lange dauert bis das Programm beendet ist. Aber dennoch danke für einen möglichen Hinweis an was es liegen könnte. Beim Debuggen wird auf jeden Fall im OnDestroy beider Klassen sehr lange gewartet. Leider kann ich nirgends irgendwie tiefer irgendwo debuggen um den Fehler zu finden.
Aber dieses Problem will ich mal etwas nach hinten schieben, es sei denn es kennt jemand eine Lösung bzw. einen Anhaltspunkt an was es liegen könnte.

[jaenicke]

Was ich noch vergessen habe:
Statt OpenKey sollte in GetPreviewHandlerCLSID noch OpenKeyReadOnly rein, damit es auch ohne Adminrechte funktioniert.

Wenn es beim Beenden hängt, hängt es bei mir in der Preview-DLL beim Unload wie man im Stacktrace ja sieht:

Insofern wird sich da wohl nicht viel machen lassen.