Heute Betriebssysteme haben mehrere Programme am Laufen, der aktuell freie Speicher ist also völlig unabhängig vom eigenen Programm. Dann gibt es noch Auslagerungsspeicher, Overcommits, etc. Ob und wann std::bad_alloc geschmissen wird ist absolut zufällig.

Es gibt auch keine gute Antwort auf ein bad_alloc. Ich darf kein File öffnen, ich darf nichts in ein File schreiben, ich darf nichtmal Strings zusammensetzen oder einen Dialog öffnen, alles könnte wieder std::bad_alloc werfen.

In meiner Erfahrung tritt der Fall so gut wie nie auf und es ist deshalb vergebene Mühe, sich darauf einzustellen. (Mal von riesigen Allokationen abgesehen, wo erwartet wird, dass die mal fehlschlagen können.)

Ich sehe immer wieder einzelne Leute, die versuchen std::bad_alloc zu berücksichtigen: http://www.c-plusplus.net/forum/320976
Und Richtlinien, dass Exceptions keine Strings halten dürfen, wegen bad_alloc.

Ich kann gut mit Programmen leben, die abstürzen wenn kein Speicher mehr verfügbar ist. Schliesslich schliesse ich als User auch Programme, wenn der Speicher ausgeht. Vielleicht ein catch(bad_alloc&) in main, aber das wars.

Wie seht ihr das?

bad_allprog schrieb:

Heute Betriebssysteme haben mehrere Programme am Laufen, der aktuell freie Speicher ist also völlig unabhängig vom eigenen Programm.

Das stimmt so nicht. Bei Übliche Betriebssysteme kannst du dir so viel Speicher allokieren wie der virtuelle Adressraum groß ist. Dieser steht jedem Program exklusiv zur verfügung, lediglich das Betriebssystem belegt davon etwas für sich selber.

In durchschnittlichen Desktop-Apps? Sehe ich genau so. Aber auf einem Server oder einem Datenbankprozess oder Ähnlichem will man lieber nicht gegen die Wand fahren, nur weil eine Allokation fehl schlägt.

Stimmt zwar, aber das verschiebt man auf OS-Level und gibt der Anwendung das Gefühl, unendlich viel Speicher zu haben.

Was soll man denn bitte machen, wenn man ein std::bad_alloc erhält?
Die einzige Möglichkeit, die ich sehe, ist Bufferspeicher freigeben, Fehlermeldung ausgeben, exit()/abort().
Genau diese Aktion macht mein new handler; bad alloc wird also gar nicht mehr geworfen.

Aufräumen, Temp-Dateien löschen, sich von Netzwerkpartnern höflich verabschieden, Datenbankverbindung kappen, ...

Also bad_alloc nicht fangen und regieren, sondern ruhig bis zur main() hochrauschen lassen.

Stimmt zwar, aber das verschiebt man auf OS-Level und gibt der Anwendung das Gefühl, unendlich viel Speicher zu haben.

Und wenn die Platte auch voll ist, was dann? Das ist jetzt auch nicht undenkbar. Zudem dürfte eine Festplatte in einige Fällen auch so langsam sein, dass ein geordneter Rückzug am Ende wünschenswerter ist. Ich fürchte, es wird einfach immer ein paar Programme geben die dieses Problem nicht einfach ignorieren können.

Nathan schrieb:

Was soll man denn bitte machen, wenn man ein std::bad_alloc erhält?

Paradebeispiel wäre z.B. das Leeren von Caches. Oder das Warten auf i/o; wenn man z.B. wartet bis das (asynchrone) Schreiben in eine Datei abgeschlossen ist, wird danach der Speicher in dem die zu schreibenden Daten standen frei gegeben. Je nach Anwendung gibt es durchaus einige Möglichkeiten, wobei das Programm danach sogar normal weiter laufen kann.

bad_allprog schrieb:

Stimmt zwar, aber das verschiebt man auf OS-Level und gibt der Anwendung das Gefühl, unendlich viel Speicher zu haben.

Und wenn die Platte auch voll ist, was dann?

Soweit darf es gar nicht erst kommen. Das Programm checkt natürlich immer mal wieder den Speicherverbrauch und unternimmt entsprechend Aktionen, den Cache verkleinern, die Anzahl Worker reduzieren, etc (z.B. alle 1sec oder im eigenen malloc). Und wenn alles nicht hilft, dann wird ein geordneter Neustart unternommen.

Sind aber alles Sachen, die du nicht machen kannst, wenn du etwas allokierst. Das muss irgendwo zentral geschehen und da ist bad_alloc hinderlich.

Also entweder bad_alloc bis auf main durchrauschen lassen oder ein kluges Memory-System ohne bad_alloc.

Soweit darf es gar nicht erst kommen. Das Programm checkt natürlich immer mal wieder den Speicherverbrauch und unternimmt entsprechend Aktionen, den Cache verkleinern, die Anzahl Worker reduzieren, etc (z.B. alle 1sec oder im eigenen malloc).

Sind aber alles Sachen, die du nicht machen kannst, wenn du etwas allokierst. Das muss irgendwo zentral geschehen und da ist bad_alloc hinderlich.

Momentchen! Dein new kann durchaus schlau sein und die Sachen alle machen. Und Dein new_handler kann durchaus Caches leeren, Worker reduzieren und ein Sekundchen warten, damit Threads auslaufen, Threads abschießen, und alles versuchen. Wenns nicht klappt, noch ein Fitzelchen Speicher zu bekommen, dann passiert halt bad_alloc. Das passt doch herrlich zusammen.

Also entweder bad_alloc bis auf main durchrauschen lassen oder ein kluges Memory-System ohne bad_alloc.

Freiwilliger Verzicht auf RAII passt mir nicht in den Kram.

Und wenn alles nicht hilft, dann wird ein geordneter Neustart unternommen.

Jo, typischerweise in der Endlosschleife in der main(), oder? Die main() muss alles fangen, so oder so.

Bei kleinen Allokationen würde ich niemals bad_alloc erwarten - an dem punkt swapt sich das System mit hoher Wahrscheinlichkeit eh gerade tot und geordnetes Abbauen ist aufgrund des überforderten Schdulers nicht mehr möglich.

Daher erwarte ich niemals bad_alloc

Windows schiebt bei 2GB pro process einen Riegel vor und dann kommt schon bad_alloc...

Windows schiebt bei 2GB pro process einen Riegel vor und dann kommt schon bad_alloc...

Nur bei 32-Bit-Anwendungen.

Auf 64 Bit Systemen sehe ich kein echtes Problem wenn man den Fall ignoriert. Wenn da ein bad_alloc fliegt ist das typischerweise zu einem Zeitpunkt wo man sowieso schon lange nicht mehr mit dem System arbeiten mag. Ausgenommen man deaktiviert das Pagefile natürlich, dann läuft alles noch halbwegs gut bis zu dem Zeitpunkt wo der Speicher alle ist.

Und wenn es dazu kommt, dann bei 64 Bit nicht weil der Adressraum alle ist (wie bei 32 Bit), sondern weil das OS wirklich keinen Speicher mehr besorgen kann.
Wodurch sich die Frage ergibt ob man dann überhaupt nen bad_alloc bekommt, oder ob das OS nicht gleich den Prozess killt. Gibt nämlich Fälle wo das OS gleich den Prozess abschiessen wird. Bzw. den entsprechenden Handler der CRT aufrufen, der dann aber auch nix machen kann als den Prozess zu terminieren.

Und selbst wenn man den bad_alloc bekommt, ist nicht sichergestellt dass das Programm weiterlaufen kann. Einen solchen Fall hab ich eh bereits in einem anderen Thread beschrieben.

EDIT: Link korrigiert.