Wann prüft ihr Speicherallokierungen?

[muemmel]

Hi,

unabhängig, ob etwas guter Stil ist, und ob man so was macht...
Die meisten Programme, die wir hier so schreiben haben irgend was mit der Arbeit anderer Leute (oder unserer eigenen) zu tun. Da nützt ein Abpfiff ohne jeden Kommentar herzlich wenig. Wenn ich noch irgendwie gesagt bekomme, daß der Speicher alle ist, dann kann ich als Nutzer was tun, merh Swap, andere Prozesse beenden, anderen Rechner nehmen oder einfach noch ein paar Maikäfer im Rechner nachrüsten. Wenn ich es aber nicht erfahre, dann weiß ich nur es geht nicht, obwohl es vielleicht mit ein paaar "Bitchen" mehr gehen würde. Also ist das Programm für mich erst mal gestorben.
Sicher gibt es Programe, wo ein Absturz keinen Schaden tut, aber das ist nicht die Regel. Meist hat man entweder schon eine Menge eingegeben, oder es sind Dateien offen oder...
Das wichtigste wofür ich als Programmierer Sorge tragen muß, ist daß mein Programm keinen Schaden anrichtet. Also zumindest offene Dateien schließen. Wenn machbar, dann auch eventuell eingegebene Daten in eine temporäre Datei speichern, oder unvollständig geäderte Daten verwerfen statt sie unkonsistent zu speichern.
Das hängt immer davon ab, was die Daten an denen das Programm arbeitet wert sind. Wenn es nur eine Stunde Arbeit ist, ist es die eine Sache, aber man muß IMMER davon ausgehen, daß es noch Kunden gibt, die keine Datensicherung kennen. Wenn dann die gesammten Geschäftsgrundlagen eines kleinen Betriebes den Bach runter sind, dann hilft der Hinweis auf Datensicherungen wenig. Da können im schlimmsten Fall Arbeitsplätze unbeteiligter dritter dranhängen.
Also auf den Punkt gebracht zumindest immer versuchen über Ressourcenknappheit zu informieren, und je nach Wert der zu bearbeitenden Daten gegebenenfalls einen Notfallplan abarbeiten, der das schlimmste verhindert.
Für eine Meldung sollte der Speicher fast immer reichen, da durch das bei einer Exception stattfindende stack unwinding ja auch wieder speicher frei wird. Aber das ist ja auch nicht das Problem. Wo ist die Schwierigkeit mal ein kleies Programm zu schreiben, dem man sagen kann wieviel Platz es belegen soll und das dann bei abgeschaltetem swap parallel starten, den Platz allemachen und gucken was passiert.

Wesentlich weniger schlimm finde ich die Verluste durch nicht wieder freigegebenen Speicher, wo z.B. Myers so viel drüber schreibt. Solange man nicht regelmäßig was vergißt tut das bei den heutigen Systemen aus meiner sicht fast gar nichts. Wenn irgend eine Seite nicht mehr benutzt wird, wird sie irgendwann sowieso vom System ausgelagert und liegt dann bis zum nächsten Neustart im swap. Wenns die Regel wird, oder bei sehr großen Speicherblöcken passiert ists aber auch da nicht schön. Aber auf keinen Fall en Argument gegen C++ wie es manche anführen, weil es da keine automatische Speicherbereinigung gibt. Aber mit sorgfältiger Programiereung und eventuell mal durch die Lappüen rutschenden Blocks denke ich kann man leben.

Gruß Steffen das Mümmel

[tntnet]

Eben hatte mein Kollege eine Exception wegen Speicherüberlauf. Das Programm hat den Fehler gemeldet und ist weiter gelaufen. Die Fehlermeldung hat ihm gleich gesagt, daß zu viel Speicher verbraucht wurde. In dem Fall hat er Daten in ein std::ostringstream geschrieben. Und zwar offensichtlich ein wenig zu viel. Der ostringstream hat einen std::bad_alloc geworfen. Der Fehler wurde abgefangen und da der ostringstream auf dem Stack lag, hat er vor dem catch den bisher verbrauchten Speicher frei gegeben, so daß die Gefahrensituation nicht mehr gegeben war und das Programm problemlos weiter arbeiten konnte.

Ist hier noch irgendjemand, der bezweifelt, daß ein Speicherüberlauf ignoriert werden sollte, da sowieso alles zu spät ist?

Gruß

Tntnet

[Artchi]

Das zweifeln wahrscheinlich nur die an, die keine kritische Software entwickeln. Und mit kritisch meine ich ganz bestimmt nicht nur Software in einem AKW! Sondern kritisch ist bei uns schon eine Planungsstoftware für die Planer eines Produktes. Aber auch ein Exceldokument ist kritische Software: wenn ich was die ganze Zeit eingebe und berechne, und aufeinmal ist alles weg, stehe ich ganz schön dumm da, wenn der Chef zum Feierabend ein Ergebnis sehen will. Völlig unerheblich ob ich vielleicht alle paar Sekunden Strg+S hätte drücken sollen.

Übrigens, auch abstürzende PC-Spiele ohne nennenswerte Angabe eines Grundes sind nervig. Und die sind nur zur Belustigung nützlich. Wenn schon der Absturz eines PC-Spiels nervt, kann man sich das bei "ernsthaften" Anwendungen vorstellen.

[yogle]

Artchi schrieb:

Übrigens, auch abstürzende PC-Spiele ohne nennenswerte Angabe eines Grundes sind nervig. Und die sind nur zur Belustigung nützlich. Wenn schon der Absturz eines PC-Spiels nervt, kann man sich das bei "ernsthaften" Anwendungen vorstellen.

Das verwundert mich auch immer. PC-Spiele an denen ein Haufen Leute sitzen und eine Menge Geld reingesteckt wird, stürzen mit Ach und Krach ab. Wieso kann man da nicht einen einfachen Exception Handler reinbauen der z.B. die Spielstände speichert und den nächsten Patch könnten sie vielleicht auch noch schneller rausbringen

[hustbaer]

Weil das eben nicht so einfach ist, Freund yogle.

z.B. kannst du schonmal davon ausgehen dass bei vielen dieser Fehler der Spielstand im RAM sowieso schon "kaputt" ist, den zu speichern bringt dann auch nixmehr.

Weiters, wenn der Fehler irgendwo mitten im Gamestate Update passiert hast du einen "Zwischenzustand" den du auch nicht sinnvoll speichern kannst.

[Bouncer]

yogle schrieb:

PC-Spiele an denen ein Haufen Leute sitzen und eine Menge Geld reingesteckt wird, stürzen mit Ach und Krach ab. Wieso kann man da nicht einen einfachen Exception Handler reinbauen der z.B. die Spielstände speichert...

kann man schon, aber es interessiert wohl keinen. ich glaube, auf irgendwelche fehlschläge wird bei spiele-codes kaum rücksicht genommen, solange der kram in den meisten fällen läuft.

[asdasdasd]

Das wäre kontraproduktiv autamatische Spielstandsicherung einzubauen! Schließlich verlängert sich dadurch die Spieldauer

Wenn man jedes mal von vorn anfangen muss....

[yogle]

hustbaer schrieb:

Weil das eben nicht so einfach ist, Freund yogle.

z.B. kannst du schonmal davon ausgehen dass bei vielen dieser Fehler der Spielstand im RAM sowieso schon "kaputt" ist, den zu speichern bringt dann auch nixmehr.

Weiters, wenn der Fehler irgendwo mitten im Gamestate Update passiert hast du einen "Zwischenzustand" den du auch nicht sinnvoll speichern kannst.

Ich weiß schon recht genau, was grundsätzlich passiert wenn ein Programm abstürtzt, das kannste mir glauben. Das man größtenteils davon ausgehen kann, dass der Spielstand im RAM eh schon "kaputt" ist, denke ich nicht. Eher umgekehrt. Denn der wohl häufigste Fehler der zu Abstürzen führt, ist die Access Violation. Da verändert sich im RAM manchmal gar nichts, manchmal schreibt/ließt man an der Stelle 0x0 im Speicher (da steht praktisch nie was), oder man verwendet uninitialisierte Pointer die dann so ausehen 0xABABABAB (geringe Chance hier was zu treffen). Natürlich gibt es noch zig andere Fehlerquellen aber naja bla... Ich will jetzt hier auch nicht über die (Un)Möglichkeit Spielstände zu speichern streiten.
Was ich wichtiger finde, ist der fehlende Feedback. Wenn das Programm abschmiert, sendet es garantiert keinen Bugreport und diese können sehr nützlich sein. Nicht umsonst hat Microsoft (endlich) die Minidumps eingebaut.

[hustbaer]

yogle schrieb:

Ich weiß schon recht genau, was grundsätzlich passiert wenn ein Programm abstürtzt, das kannste mir glauben. (...)

Ok, sorry.
Ich hatte einfach den Eindruck dass du den Aufwand von "Spielstand Speichern bei Absturz" etwas unterschätzt. Vielleicht sind wir da auch einfach nur anderer Meinung

Vonwegen Crash-Dumps schreiben - da regt es mich eher auf dass die Spieler/User so "tolerant" gegenüber Fehlern sind. Wären sie das nicht hätten wir vielleicht weniger, dafür aber bessere (stabilere) Spiele/Software.
Dass es möglich ist sieht man ja an den ganzen Konsolenspielen (PS2 Konsolen-Generation, also ohne Festplatte, also ohne Möglichkeit Patches einzuspielen). Die funktionieren eigentlich auch problemlos...

Wie der Hersteller das dann letzlich erreicht ist ja dann egal.

Grundsätzlich gebe ich dir aber recht dass es oft eine gute Idee wäre Crash-Dumps zu schreiben - allerdings IMO eher aus Sicht des Herstellers. Dem User kann es eigentlich egal sein, für den zählt nur das Ergebnis.

[yogle]

hustbaer schrieb:

yogle schrieb:

Ich weiß schon recht genau, was grundsätzlich passiert wenn ein Programm abstürtzt, das kannste mir glauben. (...)

Ok, sorry.
Ich hatte einfach den Eindruck dass du den Aufwand von "Spielstand Speichern bei Absturz" etwas unterschätzt. Vielleicht sind wir da auch einfach nur anderer Meinung

Kein Problem. Hatte mir schon so etwas gedacht, deswegen habe ich ja auch etwas ausführlicher geantwortet

hustbaer schrieb:

Vonwegen Crash-Dumps schreiben - da regt es mich eher auf dass die Spieler/User so "tolerant" gegenüber Fehlern sind. Wären sie das nicht hätten wir vielleicht weniger, dafür aber bessere (stabilere) Spiele/Software.
Dass es möglich ist sieht man ja an den ganzen Konsolenspielen (PS2 Konsolen-Generation, also ohne Festplatte, also ohne Möglichkeit Patches einzuspielen). Die funktionieren eigentlich auch problemlos...

Wie der Hersteller das dann letzlich erreicht ist ja dann egal.

Grundsätzlich gebe ich dir aber recht dass es oft eine gute Idee wäre Crash-Dumps zu schreiben - allerdings IMO eher aus Sicht des Herstellers. Dem User kann es eigentlich egal sein, für den zählt nur das Ergebnis.

Meine Rede. Von solchen Crach-Dumps profitieren im Grunde User und Hersteller. Der Hersteller kann sein Produkt schneller/einfacher verbessern was wiederum dem User zugute kommt. Deswegen ist mein derzeitiges Projekt auch ein universeller Exception Handler, der einem solche Aufgaben wie Abfangen von Exceptions, User Benachrichtigung, versenden von Bugreports usw. abnimmt Wenn ich mal fertig werden sollte, dürft ihr ihn dann auch mal ausprobieren, wenn ihr wollt