Memory Leaks aufspüren

[Helmut]

Hi,
ich suche ein Tool, mit dem man möglichst einfach Memoryleaks aufspüren kann. Aber bevor ihr sagt, dass ich googeln soll, es gibt einige Umstände, die die ganze Sache etwas schwierig machen:
-Mein Programm ist praktisch ein Plugin von einem Programm, dessen Sourcecode ich nicht habe.
-Das Leak wird nur von einem Benutzer berichtet, ich selbst kann es nicht reproduzieren. Ich will also eine Version compilieren, die die gefundenen Leaks in einer Datei speichert, welche der Benutzer mir schicken kann.
-Das Programm benutzt nicht einfach nur Speicher, sondern erstellt auch alle möglichen COM Objekte, GDI Handles, hostet JavaScript Code...

Hat da jemand eine Idee?
Grüße
Helmut

[eXile]

Der ganz große Hammer wäre wohl Dr. Memory; die Frage ist nur, ob das dein Benutzer auch in der Lage ist, das zu benutzen. Mit einer geeigneten Suppression-Datei, mit welcher nicht-relevante Call-Stacks ausgeschlossen werden, müsste das ganz gut möglich sein.

Auch die Restriktionen (x86 und Release-DLL der CRT) müssen erfüllt sein.

[antisteo]

valgrind. Da eine shared Library immer in den Adressraum des Host-Programms eingeblendet wird und dessen Speicherverwaltung nutzt, spürst du die Leaks auf, indem du valgrind mit dem Hauptprogramm aufrufst.
Handles etc. sind auch kein Problem, sind ja alles Dateien ;)

(Es gibt aber auch sprachspezifische Bibliotheken wie heaptrc, die man einfach ins Programm einbinden kann)

[Thoran]

Ich hatte mal mit einem ähnlichen Fall zu tun. Auch ein von mir geschriebenes Plugin was in einem Programm geladen wurde, dessen Quellcode nicht verfügbar war. Zum Feststellen der Memoryleaks hab ich Parallels Studio XE damals verwendet, im speziellen der Inspector XE. Leider ist das Programm etwas kostspielig, aber meiner Meinung nach einfach super wenn man an solche Probleme ran muss. Ich überlege mir sogar es mal irgendwann private zu kaufen, wenn ich denn jemals an den Punkt kommen sollte, dass ich es brauche. Immerhin kann man es mal 30-Tage testen.

[Jonathan]

@antisteo: COM Objekte und GDI Handels hören sich ganz stark nach Windows an, da würde Valgrind ausscheiden.
Mit DR Memory hab ich auch gute Erfahrungen gemacht. DAs Programm wird dadurch zwar unbenutzbar langsam, aber man findet echt fiese Fehler. Der erste Punkt könnte aber ein echtes Problem sein, wenn irgendein Nutzer den Fehler im Plugin reproduzieren soll.
Was kann heaptrc so?

[antisteo]

@antisteo: COM Objekte und GDI Handels hören sich ganz stark nach Windows an, da würde Valgrind ausscheiden.

Also LibreOffice kann OLE-Objekte auch unter Linux. Also scheint da irgendwas doch zu gehen. (wenn auch einzig und allein von LO unterstützt)

Was kann heaptrc so?

Speichert sich einen Stacktrace zu jedem malloc() und verwirft diesen bei free(). Das ganze ist Standardumfang von Freepascal. Man bindet die unit einfach ein und nach der Ausführung des Programms werden alle nicht befreiten Speicherbereiche auf stderr ausgespuckt inklusive wo sie allokiert wurden. Im Prinzip wrappt heaptrc einfach nur malloc() und free().

Hier die Ausgabe von folgendem Programm:

Code: Alles auswählen

program test;
{$mode objfpc}

uses heaptrc;

 procedure fn;
 begin
  TObject.create;
 end;

begin
 fn();
end.

Code: Alles auswählen

Heap dump by heaptrc unit
1 memory blocks allocated : 8/8
0 memory blocks freed     : 0/0
1 unfreed memory blocks : 8
True heap size : 32768
True free heap : 32608
Should be : 32632
Call trace for block $00007FB1D78E40C0 size 8
  $00000000004001BD line 6 of test.pas
  $00000000004001CE line 9 of test.pas
  $0000000000400180

[Jonathan]

@antisteo: COM Objekte und GDI Handels hören sich ganz stark nach Windows an, da würde Valgrind ausscheiden.

Also LibreOffice kann OLE-Objekte auch unter Linux. Also scheint da irgendwas doch zu gehen. (wenn auch einzig und allein von LO unterstützt)

Ja, ich hab auch gehört, dass es da wohl irgendwelche Tricks und Möglichkeiten gibt. Aber das ändert nichts daran, dass sowohl das Programm, als auch das Plugin wohl für Windows geschrieben sein wird, und dieser eine Client sich ganz sicher nicht Linux installieren wird, um eine angepasste Version des Programms laufen zu lassen, nur um ein MemoryLeak zu finden. Das war mein Punkt.

[Helmut]

Hey, danke für die Antworten.
Ich habe in den letzten Tagen versucht Dr. Memory zum Laufen zu kriegen, leider erfolglos. Es scheint unter Win8 noch nicht zu funktionieren. Dabei scheint es genau das zu sein, was ich gesucht habe.
valgrind scheint ja für Linux zu sein und fällt deshalb flach. Zumal scheint es ein simpler malloc Wrapper zu sein, Speicherallokationen vom OS würde es also nicht finden.
Parallels Studio XE scheint an VS gebunden zu sein. Ich kann einem Anwender wohl kaum zumuten VS, das Megading, und mein Projekt zu installieren :)

Naja, der Anwender schreibt auch nicht mehr zurück, wahrscheinlich war's ein anderes Plugin.
Irgendwie ärgerlich, dass 99% aller Bugreports, die bei mir reinkommen, welche sind, die ich nicht fixen kann...

[odenter]

Vielleicht hilft Dir das hier:
http://support.microsoft.com/kb/268343/en-us

Hat unter Windows 7 nocht funktioniert, ich würde jetzt erwarten das es unter Windows 8 auch funzt.

[eXile]

Es scheint unter Win8 noch nicht zu funktionieren. Dabei scheint es genau das zu sein, was ich gesucht habe.

Ach verdammt. Bei mir klappt es auch nicht. Hier ist der blockierende Bug. Grandios; mir pinkelt das auch gerade ans Bein. Wenn du einen ganz langen Atem hast, könntest du noch eine Windows-7-VM aufsetzen; ja ich weiß, das ist eine Heidenarbeit, aber mehr fällt mir auch nicht mehr ein.

Der Bug ist glücklicherweise unter den 22 kritischsten Bugs im Bug-Tracker und hat schon einen Owner. Also bald gefixt, bestimmt. :)