Gibt es eine akzeptable Grenze für Speicherlecks?
https://stackoverflow.com/questions/233258
-
04-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich habe gerade angefangen mit SDL experimentieren in C ++, und ich dachte, für Speicherlecks überprüft regelmäßig eine gute Gewohnheit sein kann, früh zu bilden.
diese mit im Sinn, ich habe meine gelaufen ‚Hallo Welt‘ Programme durch Valgrind irgendwelche Löcher zu fangen, und obwohl ich alles außer den grundlegendsten SDL_Init() und SDL_Quit() Aussagen entfernt haben, Valgrind meldet noch 120 Byte verloren und 77k noch erreichbar.
Meine Frage ist: Gibt es eine akzeptable Grenze für Speicherlecks, oder sollte ich danach streben, alle meine Code vollständig leckagefrei zu machen?
Lösung
Achten Sie darauf, dass Valgrind ist nicht falsch positive Ergebnisse in seine Messungen aufnimmt.
Viele naiven Implementierungen von Speichern Analysatoren Flag-Speicher als ein Leck verloren, wenn es nicht wirklich ist.
haben vielleicht eine Lese einige der Papiere in den externen Links Abschnitt der Wikipedia-Artikel über Entschlacken . Ich weiß, dass die Dokumentation, die mit Entschlacken kommt mehrere Szenarien beschreibt, wo Sie Fehlalarme auslösen, wenn sie versuchen, Speicherlecks zu erkennen und dann geht auf die Techniken zu beschreiben Entschlacken rund um die Themen zu erhalten verwendet.
BTW Ich bin nicht mit IBM in irgendeiner Weise verbunden. Ich habe gerade Entschlacken ausgiebig genutzt und wird für seine Wirksamkeit bürgen.
HTH.
prost,
Rob
Andere Tipps
Sie haben mit der Definition von „Memory Leak“ vorsichtig sein. Etwas, das bei der ersten Verwendung einmal zugeordnet ist, und beim Beenden des Programms befreit, wird manchmal durch ein Leck-Detektor gezeigt werden, weil sie vor diesem ersten Einsatz zu zählen begonnen. Aber es ist nicht ein Leck (obwohl es schlechtes Design sein kann, da es eine Art global sein kann).
Um zu sehen, ob ein bestimmtes Stück Code Lecks, man vernünftigerweise es einmal laufen könnte, deaktivieren Sie dann den Leck-Detektor, dann ist es wieder laufen (dies erfordert natürlich programmatische Steuerung des Lecksuchers). Dinge, die „Leck“ einmal pro Durchlauf des Programms in der Regel keine Rolle. die Dinge „Leck“ jedes Mal, wenn sie ausgeführt sind in der Regel tun Angelegenheit schließlich.
Ich habe festgestellt, selten es zu schwierig Null auf dieser Metrik zu treffen, die auf der Beobachtung kriechend Speichernutzung entsprechen als verlorene Blöcke gegenüber. Ich hatte eine Bibliothek, in der es so knifflig bekam, mit Caches und UI-Möbel und so weiter, dass ich dreimal über meine Testsuite nur lief, und ignoriert alle „Lecks“, die nicht ein Vielfaches von drei Blöcken stattfand. Ich fing noch alle oder fast alle realen Lecks und analysiert, um die heikle Berichte, sobald ich die niedrig hängenden Früchte aus dem Weg bekommen hatte. Natürlich sind die Schwächen der Testsuite für diesen Zweck verwendet werden (1) nur die Teile davon verwenden können, die Sie finden, sind die Fehler des Testcodes keinen neuen Prozess erforderlich ist, und (2) die meisten der Lecks , nicht die Bibliothek Code ...
Das Leben mit Speicherlecks (und andere unvorsichtig Ausgaben) ist, von seiner besten Seite, (meiner Meinung nach) sehr schlechte Programmierung. Im schlimmsten Fall macht es Software unbrauchbar.
Sie sollten vermeiden, dass sie in erster Linie und führen Sie die Werkzeuge, die Sie zur Einführung und andere erwähnt haben, um zu versuchen, sie zu erkennen.
Vermeiden Sie schlampig Programmierung - es gibt genug schlechte Programmierer da draußen schon -. Die Welt nicht ein anderes braucht
EDIT
Ich stimme zu - viele Werkzeuge Fehlalarme liefern
.Wenn Sie wirklich besorgt über das Gedächtnis undicht sind, müssen Sie einige Berechnungen tun.
Sie müssen Ihre Anwendung testen, wie eine Stunde und dann die durchgesickert Speicher zu berechnen. Auf diese Weise erhalten Sie einen durchgesickert Speicher Bytes / Minuten-Wert.
Nun müssen Sie die durchschnittliche Länge der Sitzung des Programms schätzen. Zum Beispiel für notepad.exe, klingen 15 Minuten wie eine gute Schätzung für mich.
Wenn ( durchschnittliche Sitzungslänge) * (durchgesickert Bytes / Minute)> 0.3 * (Speicherplatz normalerweise von Ihrem Prozess belegt) , dann sollten Sie vielleicht noch einige Anstrengungen unternehmen Speicherverluste zu reduzieren. Ich habe gerade 0,3 geschminkt, mit gesundem Menschenverstand Ihre akzeptablen Grenzwert zu bestimmen.
Beachten Sie, dass ein wichtiger Aspekt ein Programmierer zu sein, eine Software Engineer wird, und sehr oft Engineering ist über die am wenigsten schlechte Option von zwei oder mehreren schlechten Optionen wählen. Mathe immer praktisch ist, wenn Sie messen müssen, wie schlecht eine Option tatsächlich ist.
Für eine Desktop-Anwendung, sind kleine Speicherlecks kein wirkliches Problem. Für Dienste (Server) sind keine Speicherlecks akzeptabel.
Die meisten OSes (einschließlich Windows) gibt wieder alle aus einem zugewiesenen Speicher des Programms, wenn das Programm geladen ist. Dazu gehören alle Speicher, der das Programm selbst Spur verloren haben.
Da, meine übliche Theorie ist, dass es völlig in Ordnung ist Speicher während des Starts zu lecken, aber nicht OK, um es während der Laufzeit zu tun.
Also wirklich die Frage ist nicht, wenn Sie sind undicht jeder Speicher, ist es, wenn Sie ständig es Laufzeit während Ihres Programms undicht werden. Wenn Sie Ihr Programm für eine Weile benutzen, und egal, was Sie tun, bleibt es bei 120 Bytes verloren, anstatt zu erhöhen, würde ich sagen, dass Sie große getan haben. Fahren Sie fort.
Es hängt von Ihrer Anwendung. Einige undichte kann unvermeidbar sein (wegen der Zeit benötigt, um die undichte Stelle v.s. Fristen zu finden). Solange Ihre Anwendung kann so lange laufen, wie Sie wollen, und nicht eine verrückte viel Speicherplatz in dieser Zeit ist es wahrscheinlich in Ordnung.
Es sieht wie SDL Entwickler nicht Valgrind verwenden, aber ich im Grunde kümmern sich nur um jene 120 Bytes verloren.
diese mit im Sinn, ich habe meine gelaufen ‚Hallo Welt‘ Programme durch Valgrind irgendwelche Löcher zu fangen, und obwohl ich alles außer den grundlegendsten SDL_Init entfernt haben () und SDL_Quit () Aussagen, Valgrind berichtet noch 120 Bytes verloren und 77k noch erreichbar.
Nun, mit Valgrind, „nach wie vor erreichbar Speicher“ ist oft nicht wirklich durchgesickert Speicher, vor allem in einem so einfachen Programm. Ich kann mit Sicherheit darauf wetten, dass es im Grunde keine Zuordnung in SDL_Quit (), so dass die „undichte Stellen“ sind nur Strukturen einmal vergeben von SDL_Init ().
Versuchen Sie das Hinzufügen nützliche Arbeit und wenn diese Beträge erhöhen zu sehen; versuchen, eine Schleife von Nutzarbeit zu machen (wie das Erstellen und eine SDL Struktur zu zerstören) und sehen, ob die Menge des Lecks mit der Menge an Iterationen wächst. Im letzteren Fall sollten Sie den Stack-Traces der Lecks überprüfen und lösen.
Ansonsten diese 77k Lecks als „Speicher zählen, die am Programmende befreit werden sollten, für die aber sie verlassen sich auf das Betriebssystem es zu befreien.
Also, eigentlich, ich bin mehr jetzt besorgt von diesen 120 Bytes, wenn sie nicht Fehlalarme sind, und sie sind in der Regel nur wenige. Falsch positive Ergebnisse mit Valgrind sind meist Fälle, in denen Verwendung von nicht initialisierten Speicher vorgesehen ist (zum Beispiel, weil es tatsächlich ist Klotzen).
Wie pro Rob Wells' Kommentare zu Entschlacken, herunterladen und versuchen, dort einige der anderen Tools aus. Ich benutze Bounds und AQTime und haben unterschiedliche Fehlalarme in beide über die Jahre gesehen. Beachten Sie, dass der Speicherverlust auch in einer dritten Partei Komponente sein könnte, die Sie vielleicht aus Ihrer Analyse auszuschließen. Von Beispiel hatte MFC eine Reihe von Speicherlecks in den ersten Versionen anzeigen.
IMO, Speicherlecks für jeden Code sollten aufgespürt, die in eine Code-Basis wird, die eine lange Lebensdauer hat. Wenn Sie sie nicht aufspüren können, zumindest eine Notiz machen, dass sie für den nächsten Benutzer des gleichen Codes vorhanden sind.
Firstable Speicherlecks nur ein ernstes Problem sind, wenn sie mit der Zeit wachsen, da sonst die App nur ein wenig größer sehen von außen (natürlich gibt es eine Grenze, auch hier, damit die ‚schweren‘). Wenn Sie ein Leck haben, die mit der Zeit wächst könnten Sie in Schwierigkeiten. Wie viel Mühe, hängt jedoch von den Umständen ab. Wenn Sie wissen , wo der Speicher gehen und kann sicherstellen, dass Sie immer genügend Speicher haben, werde das Programm und alles andere auf dieser Maschine sind Sie noch etwas gut laufen. Wenn Sie nicht wissen, wo der Speicher jedoch geht, würde ich das Programm nicht versenden und Graben halten.
Mit SDL auf Linux insbesondere scheint es einige undichte in der zugrunde liegenden X-Windows-Bibliothek. Es gibt nicht viel können Sie über diejenigen tun (es sei denn, Sie wollen versuchen, die Bibliothek selbst zu beheben, die wahrscheinlich nicht für schwache Nerven ist).
Sie können valgrind des Unterdrückungsmechanismus (siehe --suppressions und --gen-Unterdrückungen in der valgrind Manpage) verwenden, um ihm zu sagen nicht, dass Sie mit diesen Fehlern zu stören.
Im Allgemeinen wir haben ein wenig nachsichtiger mit Drittanbieter-Bibliotheken zu sein; während wir sollten absolut nicht Speicherlecks in unserem eigenen Code übernehmen, und das Vorhandensein von Speicherlecks soll einen Faktor sein, wenn zwischen alternativen Bibliotheken von Drittanbietern wählen, manchmal ist es aber keine andere Wahl, sie zu ignorieren (obwohl es eine gute Idee sein kann, um sie zu berichten, in der Bibliothek Maintainer).
