C++ Memory Leak Prevention

SeppJ

Das ist ein bisschen als ob man nur noch zu Fuß geht aus Angst vor einem Autounfall...

Wenn man weiß was man tut, geht von dynamischer Speicherverwaltung keinerlei Gefahr aus und man kommt viel schneller zum Ziel. Und im Gegensatz zum Auto tut es nicht einmal weh, wenn man einen Unfall hat, sondern es ist lehrreich und man macht es danach in Zukunft richtig.

ipsec

Davon abgesehen sollte man natürlich new wenn möglich vermeiden (also wie z.B. in dem angesprochenem Beispiel mit lokalen Variablen).
Man schafft sich durch new nur neue Probleme wie schlechtere Handhabbarkeit, fehlende Exceptionsicherheit usw., die man bei normalen lokalen Variablen nicht hat.

Das Problem ist, dass es Fälle gibt, wo man dynamische Speicherverwaltung zwingend benötigt bzw. ohne diese Einschränkungen hinnehmen muss (z.B. bei dynamischen Arrays). In einem solchen Fall hilft dir aber RAII, das Risiko auf Memory Leaks zu minimieren.

Shade Of Mine

ipsec schrieb:

Man schafft sich durch new nur neue Probleme wie schlechtere Handhabbarkeit, fehlende Exceptionsicherheit usw., die man bei normalen lokalen Variablen nicht hat.

Deshalb gibt es RAII.
Und alle diese Probleme sind weg und wir können new überall dort verwenden wo wir es brauchen ohne uns nur das kleinste bisschen Sorgen machen zu müssen.

ipsec

Shade Of Mine schrieb:

ipsec schrieb:

Man schafft sich durch new nur neue Probleme wie schlechtere Handhabbarkeit, fehlende Exceptionsicherheit usw., die man bei normalen lokalen Variablen nicht hat.

Deshalb gibt es RAII.
Und alle diese Probleme sind weg und wir können new überall dort verwenden wo wir es brauchen ohne uns nur das kleinste bisschen Sorgen machen zu müssen.

Genau das meine ich. Aber man muss sich ja nicht erst die Probleme machen um sie danach zu lösen, wenn man sie gleich von vornerein umgehen kann (indem man z.B. eine lokale Variable, die nur innerhalb der Funktion gebraucht wird, nicht dynamisch verwaltet) - das ist aber wie gesagt nicht immer möglich und dann nimmt man RAII.

Dazu hätte ich mal eine ergänzende Frage.

Ich habe "Heap Corruption" den ich mit VS2010 nicht finden kann.

Gibt es da ein standardisiertes Vorgehen um solche Leaks zu finden?
Ich bekomme so eine # (Nummer) und eine 0x039231312 (Adresse) angezeigt.

Nukularfüsiker

heap_ schrieb:

Ich habe "Heap Corruption" den ich mit VS2010 nicht finden kann.

Gibt es da ein standardisiertes Vorgehen um solche Leaks zu finden?

Was willst du finden, Leak oder Corruption? Das sind unterschiedliche Dinge.

Leaks kann man einfach finden, wenn man die entsprechenden Debugging-Möglichkeiten der VC-Runtime einschaltet. Siehe _CrtSetDbgFlag. Da wird eine Liste mit Allokationen ausgespuckt, die nicht freigegeben wurden.

Heap Corruption kann man damit auch in manchen Fällen auch finden, aber nicht immer. Wenn der Debugger nicht anspringt, ist wohl ein Audit angesagt.

Nukularfüsiker schrieb:

Was willst du finden, Leak oder Corruption? Das sind unterschiedliche Dinge.

Wenn ich mein Programm beende, meldet er "Heap Corruption". Dazu kommen noch etwa 1000 Leaks. Wahrscheinlich werden es Abhängigkeiten sein weil sie nicht auftreten wenn Heap Korruption nicht auftritt.

Wenn du mit Audit Code Untersuchung machst dann ist es ein ewiges Unterfangen weil ich in ein etwas größeres Projekt hereingekommen bin.

Ich kann es noch nicht einmal ungefähr eingrenzen. Diese # und die Adresse sollten Helfen. Wenn ich einen Breakpoint an diese Adresse setze, passiert nichts. Mit der Nummer kann ich nichts anfangen.

Scheint doch nicht so trivial zu sein. Gibt es vielleicht ein Buch, das solches Vorgehen umfassend beschreibt? Am besten für VS20xx oder GCC

pumuckl

[quote="heap_"]

Nukularfüsiker schrieb:

Diese # und die Adresse sollten Helfen.

Nicht wirklich. Die Adresse sagt dir wo der Heap zerschossen wurde nachdem es passiert ist - wenn du das Programm nochmal laufen lässt wird es mit ziemlicher Sicherheit nicht an der selben Stelle passieren

[quote="pumuckl"]

heap_ schrieb:

Nukularfüsiker schrieb:

Diese # und die Adresse sollten Helfen.

Nicht wirklich. Die Adresse sagt dir wo der Heap zerschossen wurde nachdem es passiert ist - wenn du das Programm nochmal laufen lässt wird es mit ziemlicher Sicherheit nicht an der selben Stelle passieren

Diese Nummer ist bei mir Konstant, genau so wie die Adresse.