Wie oft unterläuft euch ein Memleak?
-
hab grad wieder einen gefunden
-
Selten bis nie, RAII ftw...
Resource Leaks und Leak ähnliche Probleme hatte ich ironischer Weise bisher fast ausschließlich nur in Sprachen mit sogenanntem Garbage Collector (C#)...
-
dot schrieb:
Selten bis nie, RAII ftw...
Resource Leaks und Leak ähnliche Probleme hatte ich ironischer Weise bisher fast ausschließlich nur in Sprachen mit sogenanntem Garbage Collector (C#)...
Wobei C# da nicht ganz so schlimm ist, hat ja wenigstens using-Bloecke.
-
dann bin ich mal wieder der einzige
-
bevor ich (vor vielen jahren) angefangen habe RAII zu verwenden hatte ich hin und wieder mal leaks.
mittlerweile so gut wie nie.
-
bei mir würd es sicher auch was bringen, wenn ich es nicht immer so übertreiben und früher ins bett gehen würde
-
dot schrieb:
Selten bis nie, RAII ftw...
Resource Leaks und Leak ähnliche Probleme hatte ich ironischer Weise bisher fast ausschließlich nur in Sprachen mit sogenanntem Garbage Collector (C#)...
Bei Speicher?
Andere Ressourcen sind ja klar, da hat man in C# manuelle Verwaltung.fclose
heißt da ebenDispose
.
-
TyRoXx schrieb:
dot schrieb:
Selten bis nie, RAII ftw...
Resource Leaks und Leak ähnliche Probleme hatte ich ironischer Weise bisher fast ausschließlich nur in Sprachen mit sogenanntem Garbage Collector (C#)...
Bei Speicher?
Andere Ressourcen sind ja klar, da hat man in C# manuelle Verwaltung.fclose
heißt da ebenDispose
.Bei Speicher wohl in der Regel nur Leak ähnliche Probleme, da es aufgrund des GC natürlich keine vollwertigen Leaks gibt. Was allerdings nicht heißt, dass einer Anwendung nicht schonmal der Speicher ausgehen kann, weil der GC sich mal wieder völlig merkwürdig verhält. Und dann kannst du mit GC.Collect() rumlaufen, stochastisch "manuelle" Speicherverwaltung betreiben und ganz viel hoffen.
Andere Ressourcen sind leider klar, da der, durch den GC eingeführte, Nichtdeterminismus von Lebensdauern jegliches Management von anderen Ressourcen als den GC Heap unglaublich effektiv verhindert. Wie du schon festgestellt hast, versetzt der GC uns da mit einem Schlag auf den Stand der 1970er Jahre (fclose) zurück...
-
Auf der einen Seite sollen komplexe Maschinen/Prozess/... gesteuert werden und dann schafft man es nichtmal die Anzahl der new/delete ausgeglichen zu halten. Von C++ gut bescherschen kann dann nicht die Rede sein.
-
den letzten Memleak hatten wir vor ca. 2 Jahren gefunden. Der Code dazu war mehr als 10 Jahre alt und stammte noch knapp aus der "vor-shared_ptr"-Zeit. Dass das Problem erst nach so langer Zeit hoch kam, lag daran, dass hier nur ca. 20 Bytes allokiert worden sind. Und erst nachdem sich durch äußere Umstände die Aufruffrequenz sehr deutlich gesteigert hat, kam es wirklich nach mehreren Stunden Programmlaufzeit zum 'out of memory'.
Mal von diesem 'Gruß aus der Vergangenheit' abgesehen, haben wir seit konsequenter Anwendung von RAII - i.A. in Form eines Smart-Pointers - genau NULL Probleme mit Resource Leaks aller Art. Solche Fehler - inklusive des oben erwähnten - sind verdammt schwer zu lokalisieren. Wir hatten in den 90'gern mindestens einen Fall, bei dem wir fast einen Kunden verloren haben. Ursache war ein HANDLE-Leak. Das Problem war dabei gar nicht, dass ein Fehler in der SW war, sondern, dass es so lange dauerte, ihn zu finden - und also zu beseitigen. Das kostet richtig Geld und Reputation.
Wer heutzutage C++ programmiert ohne RAII arbeitet einfach unprofessionell.C++ braucht eben keinen Garbage Collector, weil C++ mit RAII keinen Carbage macht
Gruß
Werner
-
Den letzten richtig bösen Leak hatte ich mit einem speziellen, von der Uni gepfleften, Framework. Ein simulierter Joystick, allokierte bei jedem Event Resourcen, welche nicht freigegeben wurden. Das hatte zur Folge dass nach cirka 3 Minuten Joystick-Bewegung das System komplette einfrohr, da ich auf einem Echtzeit-Betriebsystem arbeitete.
Unter der WinApi habe ich auch ab und zu ein paar Leaks. Aber alle Leaks waren selbst bei exzessiver Nutzung nicht größer als 100 kByte.
-
Keine Memleaks, da keine dynamische Allokation von Speicher.
-
Alle reden hier von RAII, aber auch ohne sollte ein Entwickler in der Lage sein, Memorz Leaks schon beim Programmieren zu vermeiden. Wenn das schon schwer ist, dann liegt einem wohl Programmieren im Allgemeinen nicht.
-
nun, so selten sind die dinger auch wieder nicht
-
knivil schrieb:
Alle reden hier von RAII, aber auch ohne sollte ein Entwickler in der Lage sein, Memorz Leaks schon beim Programmieren zu vermeiden. Wenn das schon schwer ist, dann liegt einem wohl Programmieren im Allgemeinen nicht.
Abgesehen davon, dass die Aussage an sich schon völlig schwachsinnig ist (was heißt in der Lage sein? 10 mal so lange an einem Segment sitzen und dann viel unübersichtlicheren Code haben?), ist es in C++ aufgrund von Exceptions nicht mal theoretisch möglich, ohne RAII Leaks zu vermeiden. Lieber jemanden der RAII vernünftig einsetzen kann, als jemanden der den Code mit deletes zu pflastert.
-
knivil schrieb:
Alle reden hier von RAII, aber auch ohne sollte ein Entwickler in der Lage sein, Memorz Leaks schon beim Programmieren zu vermeiden.
Und wie macht man das deiner Meinung nach am besten?
-
knivil schrieb:
Auf der einen Seite sollen komplexe Maschinen/Prozess/... gesteuert werden und dann schafft man es nichtmal die Anzahl der new/delete ausgeglichen zu halten. Von C++ gut bescherschen kann dann nicht die Rede sein.
Wer ist "man"?
knivil schrieb:
Alle reden hier von RAII, aber auch ohne sollte ein Entwickler in der Lage sein, Memorz Leaks schon beim Programmieren zu vermeiden. Wenn das schon schwer ist, dann liegt einem wohl Programmieren im Allgemeinen nicht.
Wieso sollte man absichtlich auf RAII verzichten? Um zu zeigen, "wie gut einem Programmieren liegt"?
-
Einfach nur "die Anzahl der new/delete ausgeglichen zu halten" ist kein gutes Rezept, wenn man Memory Leaks vermeiden will...
-
cooky451 schrieb:
ist es in C++ aufgrund von Exceptions nicht mal theoretisch möglich, ohne RAII Leaks zu vermeiden.
Das was der Compiler da zusammenbaut, sollte man eigentlich auch von Hand nachbauen können. Ist halt unendlich umständlich und man muss bei jeder kleinen Änderung im Code aufpassen, den Abräumcode anzupassen. Daher ist es eine gute Idee, dass man das den Compiler automatisch erledigen lässt.
-
Ohne Wertung: Ohne RAII arbeitet man logischerweise nur bei Code, der auch Exceptions äußerst sparsam einsetzt.