Computerabsturz durch einfaches C++-Programm

[berni42]

Bislang bin ich immer davon ausgegangen, dass ein Anwenderprogramm (ohne root- oder andere Sonderrechte), den Computer unter Linux nicht zum Abstürzen bringen kann. Gestern wurde ich da eines besseren belehrt und frage mich nun, ob meine Annahme falsch ist, oder ob es sich um einen Fehler im Betriebssystem handelt. Das fragliche Programm sieht so aus:

Code: Alles auswählen

#include <vector>

int main()
{
    std::vector<int*> v;

    while (true) {
        v.push_back(new int[1000]);
    }
}

Es ist klar, was passiert: Irgendwann ist der Speicher voll und es wird neuer allociert, was ja nicht mehr klappen kann. Bei mir friert dann X komplett ein und der Rechner reagiert auf gar nichts mehr, selbst der Festplattencache wird nicht mehr geschrieben. Das einzige, was noch geht, ist ein Hardware-Reset.

Nun die Frage: Ist das so normal? Und wenn nein, wie kann ich (z.B. nach einem Neustart) herausfinden, wo ich nach dem Fehler suchen muss? (Im Syslog und in .xsession-errors habe ich schon geschaut, aber nichts gefunden...)

[eggy]

Das einzige, was noch geht, ist ein Hardware-Reset.

oder warten

Such mal nach Infos zu oom-killer (out of memory killer). Eine etwas ältere Erklärung findest Du hier https://www.kernel.org/doc/gorman/html/ ... nd016.html

[MSfree]

Das einzige, was noch geht, ist ein Hardware-Reset.

oder warten

Vor allem, warten, bis der komplette Swapspace aufgebraucht ist und das kann bei entsprechende Größe dauern. Daß das System dabei praktisch nicht mehr reagiert, ist ärgerlich aber völlig normal. Irgendwann killt der Kernel den Speicherfresser von selbst. Danach dauert es aber noch ein ganze Weile, bis alles, was vorher mühselig rausgeswapt wurde, wieder reinzuladen, und auch aus Maus und Tastatur wieder reagiert wird.

[Lord_Carlos]

Es ist klar, was passiert: Irgendwann ist der Speicher voll und es wird neuer allociert, was ja nicht mehr klappen kann. Bei mir friert dann X komplett ein und der Rechner reagiert auf gar nichts mehr, selbst der Festplattencache wird nicht mehr geschrieben. Das einzige, was noch geht, ist ein Hardware-Reset.

Ich glaube das geht auch mit einer Fork bomb: :(){ :|:& };:
Einfach in ein Bashterminal eingeben :)

[MSfree]

Einfach in ein Bashterminal eingeben

OK, ich probier's gleichmal bei unserem SVN-Server aus, und schaue dann ganz unschuldig in die Gegend

[uname]

Kann man nicht mit "ulimit" irgendwas bewirken? Nutzt das jemand?

[MSfree]

Kann man nicht mit "ulimit" irgendwas bewirken?

Natürlich, siehe ulimit -a

Nutzt das jemand?

Nein, ich nutze auch keinen Swapspace. Die Speichergrenze wird bei mir erreicht, ohne daß die Platte zu swappen anfängt, das System bleibt dadurch immer reaktionsfähig.

[berni42]

Vor allem, warten, bis der komplette Swapspace aufgebraucht ist und das kann bei entsprechende Größe dauern. Daß das System dabei praktisch nicht mehr reagiert, ist ärgerlich aber völlig normal. Irgendwann killt der Kernel den Speicherfresser von selbst. Danach dauert es aber noch ein ganze Weile, bis alles, was vorher mühselig rausgeswapt wurde, wieder reinzuladen, und auch aus Maus und Tastatur wieder reagiert wird.

Das heißt, es würde noch nicht mal was helfen, wenn ich im Code abfrage, ob Speicher allociert werden konnte, denn der ist ja tatsächlich noch verfügbar. Gibt es da denn einen praktischen Weg, wie man rechtzeitig die Kurve kriegen, sprich so eine Schleife vor dem exzessivem Swappen beenden kann?

[MSfree]

Gibt es da denn einen praktischen Weg, wie man rechtzeitig die Kurve kriegen, sprich so eine Schleife vor dem exzessivem Swappen beenden kann?

Du könntest z.B. /proc/meminfo überwachen, der Wert für MemAvailable zeigt die Menge des freien RAMs an.

[wanne]

Wenn man Hardware-Reset drückt kann dein Betriebssystem wenig machen. Da stürtzt jedes System ab.
Davor war dein System garantiert nicht abgestürtzt. Nur eine moderne grafische Oberfläche während dem Swapen zu nutzen braucht Geduld, die man heute nicht mehr so gewöhnt ist.

Du kannst immer die Sys-Rescue-Tasten drücken, und die werden auch vergleichsweise schnell (<3s (Das ist fefühlt verdammt lange) tun.

Aber irgend wann wird dir der Speicher wirklich voll laufen, und dann werden dir irgend welche Prozesse gekillt. (Und das ist dann ganz gerne mal deine grafische Oberfläche.)

Gegen versehentlich Amok laufende Prozesse kannst du ulimit -v setzen. Startet ein Programm aber mehrere Prozesse greift das nicht mehr (Du kannst da einfach ein fork() in die Schleife einbauen Dann legt dein Programm den Rechner wirklich Sekundenbruchteile auf absolute Unbenutzbarkeit lahm.) Früher war das üblich. Aber heute gibt es ja viele Programme die durchaus so viele Resourcen brauchen. (Spiele, Multimediabearbeitung…)
Für sowas gibt es dann cgroups, die man limitieren kann.
Daneben gibt es die möglichkeit solche Programme mit niedrigerer io-priorität (bzw andere wichtige mit höherer) laufen zu lassen. Das macht ohne Prozesse abzuschießen.

Aber prinzipiell hast du an deinem PC nunmal nicht beliebig viele Resourcen. Irgend wann ist halt Schluss. Braucht ein Programm hast du halt die drei Möglichkeiten, wenn ein Programm immer mehr Resourcen anfordert:
* Solange noch was (egal wie langsames) da ist geben und das system langsam immer mehr überlasten und kaum noch benutzbar sein.
* Das Programm abschießen.
* Dem Progamm die Resourcen geben, aber andere bevorteilt behandern die nicht gar


Per default ist linux halt drauf ausgerichtet alles dafür zu tun, dass das system NICHT abstürtzt sondern imer langsamer wird. Viele bevorzugen das anders. ulimit oder SWAP abschaffen ist da z.B. eine Methode.

[berni42]

Du könntest z.B. /proc/meminfo überwachen, der Wert für MemAvailable zeigt die Menge des freien RAMs an.

Ich bin gestern bei ähnlicher Recherche auf /proc/self/status gestoßen, wo man den Speicherplatz ablesen kann, den das eigene Programm derzeit verwendet. Aber es ist etwas umständlich das auszulesen. Danach habe ich noch sysinfo(2) gefunden. Damit kann man den freien Speicherplatz recht elegant mit folgendem Code auslesen:

Code: Alles auswählen

#include "sys/types.h"
#include "sys/sysinfo.h"
...
struct sysinfo memInfo;
sysinfo (&memInfo);
long freeram = memInfo.freeram*memInfo.mem_unit;

Allerdings muss man dabei bedenken, dass ein Teil des Speicherplatzes für root reserviert ist. Man sollte also vorher einmal 3*memInfo.totalram*memInfo.mem_unit/100 ausrechnen und das dann als untere Grenze setzen (oder noch etwas mehr Platz lassen).

Irritiert bin ich etwas darüber, dass der Computer schon bei leichtem Überschreiten dieser Grenze "abstürzt" und dann auch langes Warten (ca. 1/2 Stunde) nichts mehr nutzt, selbst wenn der Prozess gar keinen neuen Speicher mehr an sich zieht.

Und damit komme ich auch schon auf einen anderen Punkt:

Du kannst immer die Sys-Rescue-Tasten drücken, und die werden auch vergleichsweise schnell (<3s (Das ist fefühlt verdammt lange) tun.

Auf der Suche, was du mit "Sys-Rescue-Tasten" meinen könntest, bin ich auf ALT-Gr-Drucken-F gestossen. Theoretisch sollte man damit den Prozess, der am meisten Speicher verbraucht, killen können. Das kann ich nicht bestätigen; zumindest hat sich da nach minutenlangen Warten nichts getan. ALT-Gr-Drucken-B funktioniert, da startet der Rechner neu - die Festplatte wurde da nicht synchronisiert, auch nicht bei vorangehendem Alt-Gr-Drucken-S. Strg-Alt-Entf und Strg-Alt-Backspace hatten auch keine Wirkung.

[dufty2]

Yo, gemeine Sache:

Code: Alles auswählen

$ grep -i sysr /boot/config-4.8.0-2-amd64 
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6

und wenn man das (0x1b6 = 438) mit
https://www.kernel.org/doc/Documentation/sysrq.txt
vergleicht, fehlt dann halt
64 = 0x40 - enable signalling of processes (term, kill, oom-kill)

[wanne]

Auf der Suche, was du mit "Sys-Rescue-Tasten" meinen könntest, bin ich auf ALT-Gr-Drucken-F gestossen. Theoretisch sollte man damit den Prozess, der am meisten Speicher verbraucht, killen können. Das kann ich nicht bestätigen;

Unter Debian ist das deaktiviert. Bis zum nächsten Boot Aktivieren kannst du das wieder mit demda

Code: Alles auswählen

echo $(($(cat /proc/sys/kernel/sysrq)|64)) > /proc/sys/kernel/sysrq

Dauerhaft aktivieren kannst du das mit

Code: Alles auswählen

echo "kernel.sysrq = $(($(cat /proc/sys/kernel/sysrq)|64))" >> /etc/sysctl.conf

Ich wette das geht auch schöner. Ich kenne aber keine.
Duku findet Google da: https://www.mjmwired.net/kernel/Documentation/sysrq.txt

die Festplatte wurde da nicht synchronisiert, auch nicht bei vorangehendem Alt-Gr-Drucken-S. Strg-Alt-Entf und Strg-Alt-Backspace hatten auch keine Wirkung.

Alt-Drucken-S Alt-Drucken-U Alt-Drucken-B Sollte eigentlich ohne Probleme funktionieren.
Zwinschen drin solltest du ihm aber wirklich 30s zum syncen geben. (Stoppe das mal das ist verdammt lange) Du hast ja gemerkt, der reagiert nicht mehr ganz schnell
Ich benutze eigentlich fast ausschließlich Alt-Druck-R wenn sich mal wider der Grafiktreiber killt.
Strg-Alt-O müsste für dich noch interessant sein. Habe den aber nie ausporbiert. Der tut wohl auch nicht überall.
Von dem Strg-Alt-Backspace solltest du allerdings wirklich was sehen. Allerdings fragt er da bei der Installation ohne weitere Erklärung, ob das aktiviert werden soll. Vielleicht ist das aus.

Edit: dufty2 war schneller.

[berni42]

und wenn man das (0x1b6 = 438) mit
https://www.kernel.org/doc/Documentation/sysrq.txt
vergleicht, fehlt dann halt
64 = 0x40 - enable signalling of processes (term, kill, oom-kill)

Super, danke! Das war's! (Ich habe kernel.sysrq=1 in die /etc/sysctl.conf eingefügt.)

[Lofter]

MAnchmal sinds die kleinen Dinge Wald und Bäume