Frage:

Gibt es eine einfache Möglichkeit, eine Liste von zu erhalten?Typen von Ressourcen, die in einer laufenden Anwendung lecken? IOW durch Verbinden mit einer Anwendung?

Ich weiß, dass memproof das kann, aber es verlangsamt sich so sehr, dass die Anwendung nicht einmal eine Minute hält. Die meisten Taskmanager-Likes können die Nummer anzeigen, aber nicht den Typ.

Es ist kein Problem, dass die Überprüfung selbst katastrophal ist (hält den App-Prozess an), da ich mit einem Task-Manager überprüfen kann, ob ich in der Nähe bin (oder zumindest hoffe ich)

Alle anderen Erkenntnisse zur Suche nach Ressourcenlecks (also nicht nach Speicher) sind ebenfalls willkommen.

Hintergrund:

Ich habe eine Delphi 7/2006/2009 App (kompiliert mit allen drei) und nach ein paar Wochen fängt sie an, sich lustig zu benehmen. Es läuft jedoch nur auf einem der Orte, auf mehreren anderen Systemen, bis der Strom ausfällt.

Ich habe versucht, einen Debug-Code einzufügen, um das Problem einzugrenzen. und stellte fest, dass die Ausnahme EOutofResources beim Speichern einer Datei ist. (Das Speichern von Dateien kann tausende Male am Tag erfolgen.)

Ich habe versucht, Speicherlecks (mit FastMM) herauszufinden, aber da der Datenfluss ziemlich hoch ist (60 MByte / s von Gigabit-Industriekameras), kann ich nur "kriechende" Speicherlecks mit FastMM ausschließen, nicht schnelle Blitze von Memoryleaks dieses Auspuffs Erinnerung um die Zeit, zu der es passiert. Wenn etwas schief geht, füllt die App den Speicher in weniger als einer halben Minute.

Hauptverdächtige sind Dateihandles, die auf Fehler zurückzuführen sind, und TMetafiles (die in diese Dateien gestreamt werden). Kleinere Verdächtige sind VST, Popup-Menü und Tframes

Aktualisierung:

Ein weiterer möglicher Tipp: Mit D7 lief es zwei Jahre lang einwandfrei, und jetzt gibt es Probleme mit dem Turbo Explorer (den ich für stabile Projekte verwende, die nicht auf D2009 konvertiert wurden).

Paul-Jan: Da dies nur einmal pro Woche vorkommt (und dies auch nachts passieren kann), ist die Informationsbeschaffung langsam. Aus diesem Grund stelle ich diese Frage und muss Sachen kombinieren, wenn ich Donnerstag da bin. Kurz gesagt: Nein, ich weiß es nicht 100% sicher. Ich beabsichtige, die gesamte Systemtools-Sammlung mitzubringen, um zu prüfen, ob ich etwas finden kann (da es dann tagelang ausgeführt wird). Es besteht auch die Möglichkeit, dass ich geöffnete Dateien sehe. (Vielleicht sollten Sie versuchen, ein paar zu finden und es zu planen)

Aber die App sieht sehr wenig GUI-Aktion (es ist eine Machine-Vision-Inspection-App), außer Bildschirmaktualisierung +/- 15 / s, die tbitmap stretchdraw + tmetafile ist, aber ich bekomme diese Fehlermeldung beim Speichern auf die Festplatte (TFileStream) wahrscheinlich behandeltJa wirklich erschöpft. Im selben Stream wird TMetafile jedoch auch gespeichert, was bei späteren Apps nicht mehr der Fall ist und sie können ab Monaten ausgeführt werden.

------------------- UPDATE

Ich habe gesucht und gesucht und gesucht und es geschafft, die Probleme zwei- oder dreimal in vitro zu reproduzieren. Die Probleme traten auf, wenn der Speicherplatz +/- 256 MB betrug (die Systeme haben 2 GB), Benutzerobjekte 200, GDI-Objekte 500 und nicht eine Datei mehr als erwartet geöffnet waren.

Das ist nicht wirklich außergewöhnlich. Ich stelle zwar fest, dass ich kleine Mengen von Handles verliere, wahrscheinlich, weil Frames repariert wurden (etwas in der VCL scheint HPalettes zu verliern), aber ich vermute, dass die Hauptursache ein anderes Problem ist. Ich verwende TMetafile wieder und lösche es dazwischen. Ich denke, dass das Löschen der Metadatei die Größe der Ressource nicht wirklich (immer?) Ändert, schließlich wird jede Metadatei im gesamten Pool von tmetafile auf die maximale Größe gebracht, und mit 20-40 + tmetafiles (die jeweils mehrere 100 KB groß sein können) wird dies den Desktop treffen Heap-Limit.

Das ist die Theorie, aber ich werde versuchen, dies zu überprüfen, indem ich das Desktop-Limit beim Kunden auf 10 MB setze. Es wird jedoch einige Wochen dauern, bis ich eine Bestätigung erhalte, wenn sich etwas ändert. Diese Theorie bestätigt auch, warum diese Maschine etwas Besonderes ist (es ist möglich, dass diese Maschine im Durchschnitt etwas größere Metadateien hat). Gelegentlich kann es auch hilfreich sein, eine Metadatei im Pool freizugeben und neu zu erstellen.

Glücklicherweise wurden alle diese Probleme (sowohl Metafile als auch Reparenting) bereits in neueren Generationen der Apps entwickelt.

Aufgrund der besonderen Umstände (und der Tatsache, dass ich nur sehr begrenzte Testfenster habe) wird dies eine Weile dauern, aber ich habe beschlossen, den Desktop-Heap vorerst als Beispiel zu akzeptieren (obwohl das GDILeaks-Zeug auch etwas nützlich war).

Eine andere Sache, die das Audit ergab, war die Verwendung von GDI-Typen in einem Thread (obwohl nur Tmetafiles gespeichert wurden, die nicht für Streams verwendet oder anderweitig verbunden wurden).

------------- Update 2.

Das Erhöhen des Desktop-Limits schien die Zeit bis zum Auftreten des Problems nur geringfügig zu verlängern.

Leider kann ich dies nicht weiter verfolgen, da die Computer auf eine neuere Version des Frameworks aktualisiert wurden, bei der das Problem nicht auftritt.

Zusammenfassend kann ich nur sagen, welche drei Kernmodifikationen vom alten zum neuen Framework gingen:

Ich ändere keine Bildschirme mehr, indem ich Frames repariere. Ich arbeite jetzt mit Formularen, die ich verstecke und zeige. Ich habe dies geändert, da ich aufgrund dessen auch sehr seltene Abstürze oder Ausnahmen hatte (die weggeklickt werden konnten). Die Abstürze waren zwar alle während der Bedienung der GUI, nicht spontan wie das HauptproblemDie Routine, in der der Absturz stattfand, befasste sich mit TMetafile. TMetafile wurde entworfen und durch ein einfacheres, selbst erstelltes Format ersetzt. (Grundsätzlich Arrays mit Opengl Vertices)Das Zeichnen geschah nicht mehr mit tbitmap mit einer darüber gezeichneten tmetafile-Überlagerung, sondern mit OpenGL.

Natürlich könnte es auch etwas anderes sein, das beim Umschreiben der obigen Teile geändert wurde und einen sehr bösen Detailfehler behebt. Es müsste ein extrem schlechtes sein, da ich das obige System so gut ich konnte analysiert habe.

Aktualisiert November 2012 Nach einer privaten E-Mail-Diskussion: Im Nachhinein hätte der nächste Schritt darin bestanden, den Metadateien einen Zähler hinzuzufügen und sie einfach alle x * 1000 Verwendungen oder so erneut zu aktivieren und zu prüfen, ob sich dadurch etwas ändert. Wenn Sie ähnliche Probleme haben, versuchen Sie herauszufinden, ob Sie regelmäßig dynamisch zugewiesene Ressourcen zerstören und neu initialisieren können.