Wenn es bekannt ist, dass eine Anwendung Speicher (wenn ausgeführt) verliert, was sind die verschiedenen Möglichkeiten zum Suchen solcher Speicherverlustfehler im Quellcode der Anwendung.
Ich kenne bestimmte Parser / Tools (die wahrscheinlich eine statische Analyse des Codes durchführen), die hier verwendet werden können, aber gibt es noch andere Möglichkeiten / Techniken, spezifisch für die Sprache (C / C ++) / Plattform?
Es gibt Valgrind und wahrscheinlich auch andere großartige Werkzeuge. Aber ich sage dir, was ich tue, das funktioniert sehr gut für mich, da ich oft in Umgebungen code, in denen du Valgrind nicht ausführen kannst:
Ich denke, dass Valgrind das beste Werkzeug für diese Aufgabe ist.
Für Windows: Siehe Thema: Gibt es einen guten Valgrind-Ersatz? für Windows?
Es gibt zwei allgemeine Techniken zur Erkennung von Speicherlecks, dynamische und statische Analysen.
In der dynamischen Analyse führen Sie den Code aus, und ein Tool analysiert den Lauf, um zu sehen, welcher Speicher am Ende geleakt wurde. Die dynamische Analyse ist in der Regel sehr genau, analysiert jedoch nur genau, welche spezifischen Ausführungen Sie in Ihrem Tool ausführen. Wenn also einige Ihrer Schwachstellen nur für bestimmte Eingaben auftreten und Sie keinen Test haben, der diese Eingabe verwendet, werden diese Lecks durch die dynamische Analyse nicht erkannt.
Bei der statischen Analyse wird der Quellcode analysiert, um alle möglichen Codepfade zu erstellen und festzustellen, ob in einem dieser Pfade ein Leck auftreten kann. Während die statische Analyse im Moment ziemlich gut ist, ist sie nicht perfekt - Sie können nicht nur falsche Negative erhalten (die Analyse vermisst Leaks), Sie können auch falsche Positive erhalten (das Tool behauptet, Sie hätten ein Leck, wenn es gar keins gibt).
Es gibt viele dynamische Analysewerkzeuge, einschließlich so bekannter Tools wie Valgrind (Open Source, aber beschränkt auf x86 Linux und Mac) und Purify (kommerziell, aber auch verfügbar für Windows, Solaris und AIX). Wikipedia hat eine anständige Liste von einigen anderen dynamischen Analysewerkzeugen .
Auf der statischen Analyseseite ist das einzige Werkzeug, das ich für lohnend hielt, Coverity (kommerziell). Noch einmal, Wikipedia hat eine Liste von vielen anderen statischen Analyse-Tools .
Purify wird einen scheinbar wunderbaren Job damit machen
Nicht nur Speicherverluste, sondern viele andere Arten von Speicherfehlern.
Es funktioniert, indem Sie Ihren Maschinencode in Echtzeit instrumentieren, so dass Sie keine Quelle benötigen oder mit bestimmten Optionen kompilieren müssen.
Passen Sie einfach Ihren Code mit Purify an (einfachste Methode, dies zu tun: CC="purify cc" make ), führen Sie Ihr Programm aus, und erhalten Sie eine nette GUI, die Ihre Lecks und andere Fehler anzeigt.
Verfügbar für Windows, Linux und verschiedene Varianten von Unix. Es gibt einen kostenlosen Test-Download zur Verfügung.
Wenn Sie intelligente Zeiger verwenden und eine Tabelle von ihnen behalten, können Sie sie analysieren, um zu ermitteln, welchen Speicher Sie noch verwenden. Stellen Sie entweder ein Fenster bereit, um es anzuzeigen, oder häufiger, streamen Sie in ein Protokoll, bevor das Programm beendet wird.
Was das manuelle Vorgehen betrifft, glaube ich nicht, dass es etablierte Praktiken gibt. Um den Code mit einem feinzackigen Kamm zu durchsuchen, suchen Sie nach new s ( alloc s) ohne entsprechende delete s ( free s), alles was dazu gehört.
Es gibt nicht viele allgemeine Richtlinien zum Auffinden von Speicherlecks. Glücklicherweise gibt es eine einfache Richtlinie für verhindern die meisten Lecks, sowohl von Arbeitsspeicher als auch von anderen Ressourcen: Verwenden Sie RAII (Resource Acquisition Is Initialisierung), und sie werden einfach nicht beginnen mit. Der Name ist eine lausige Beschreibung, aber wenn Sie darauf googlen, sollten Sie einige nützliche Treffer erhalten.
Persönlich würde ich empfehlen, alle Variablen, die Sie zum Reservieren / Freigeben von Speicher benötigen, mit der Klasse clone_ptr zu umbrechen, die die gesamte Zuweisung von Speicher für Sie durchführt, wenn sie nicht mehr benötigt wird. Daher müssen Sie delete nicht verwenden. Es ist sehr ähnlich zu auto_ptr . Der Hauptunterschied besteht darin, dass Sie sich nicht mit dem heiklen Besitzübertragungsteil beschäftigen müssen. Weitere Informationen und Code auf clone_ptr finden Sie hier .
Tags und Links c memory-leaks c++