staging.inyokaproject.org

Mir ist aufgefallen, dass Linux (Ubuntu) bei Programmen, die in einer Endlosschleife hängen und unendlich viel Speicher reservieren, einfriert. Ist mir schon in der Praxis bei einem Programm passiert, hat ne viertel Stunde gedauert bis ich auf der Konsole (STRG + ALT + F2) killall eingeben konnte.
Hier mal folgendes Beispiel-Programm:

int main()
{
	while(1)
	{
		new int;
	}
} 

Wenn ich das ausführe dauert es nicht lange da fängt meine Maus an zu stocken. Nach weiteren 10 Sekunden hört die Musik die ich im Hintergrund abspiele auf und schließlich reagiert nichts mehr. Nun drücke ich STRG + ALT + F2. Nach einigen Sekunden erscheint die Konsole. Ich versuche mich einzuloggen komme, allerdings komme ich nicht über den Punkt, dass mir ein Text angezeigt wird, der über Ubuntu und Warranty handelt, also ~$ erscheint nicht. Nach 2 Minuten habe ich aufgegeben und meinen PC per Dauerdrücken auf den Powerknopf ausgemacht.

Das gleiche unter Windows: Auch nach 2 Minuten kann ich die Maus noch bewegen und einige Mouseovereffekte reagieren mit starker Verzögerung. Wenn ich STRG+ALT+ENTF drücke öffnet sich nach 20 Sekunden der Taskmanager in dem ich das Programm auswähle und beende. Nun ist alles noch etwas ruckelig, aber nach 5 Minuten ist das System wieder normal.

Hab das ganze mit Zwei PCs getestet und der Ablauf ist ungefähr gleich. Wie kommt es, dass Linux hierbei in die Knie geht?

warum sollte man ubuntu in eine endlosschleife hängen?

Lumines hat geschrieben:

warum sollte man ubuntu in eine endlosschleife hängen?

sollte man nicht, wieso fragst du?

Das Problem ist ja nicht die Endlosschleife, sondern das du bis in die unendlichkeit Speicher reservierst und nicht mehr freigibst. Für den Kernel gibt es dabei genau 2 Möglichkeiten: Davon ausgehen das du weißt was du tust und dich machen lassen, oder den OOM-Killer beauftragen dem schlimmsten Verbraucher die Hölle heiß zu machen oder wenn das nicht geht allen anderen die Hölle heiß zu machen, bis wieder genug Ressourcen da sind im ordentlich zu arbeiten.

Es gibt Mechanismen gegen sowas, warum sie in deinem Fall nicht greifen bzw. wohl einfach zu spät greifen: Keine Ahnung. Aber im Normalfall geht man ja nicht davon aus das sich jemand nur zum Spass speicher reserviert und jeden einfach so töten der sich eine Menge Speicher reserviert funktioniert auch nicht. Eingegriffen wird immer erst dann, wenn es fast zu spät ist, alles andere wäre komplett unvorhersehbares Verhalten.

Wobei man die Speichermenge, die ein einzelner User reservieren darf, limitieren kann. Nur gibt's dafür weder Standardbedarf noch sinnvolle Standardwerte, also ist's zunächst mal aus und man muss es konfigurieren, wenn man's braucht.

Wie SirSiggi schon bemerkt hat liegt es nicht an der Endlosschleife, sondern daran das immer mehr Speicher alloziert wird. Dadurch ist das Betriebssystem (egal ob Linux oder Windows) nach einer Weile nur noch damit beschäftigt Teile des Arbeitsspeichers auf der Platte ein- und auszulagern.

Ich glaube so lässt sich ein Problem erklären, welches ich mal hatte..

Da fing auf einmal die Festplatte wie verrückt an zu rattern und nix half mehr, ich sah nur noch das der SWAP Pralle voll war. War wohl ein Fehler in einem der laufenden Programme, oder?

Als Randbemerkung, dass bei Windows die Maus auch dann noch funktioniert wenn der PC aus dem letzte Loch pfeift ist zwar ein nettes feature, aber eigentlich das Ergebnis einer Designschäche. Und zwar sind in Windows große Teile des Window und GUI Systems direkt in den Kernel eingebaut, man mag es finden wie man will, aber dies ist einer der Gründe warum ein Windows System nur schwer genug abgespeckt werden kann embedded eingesetzt zu werden und das es relativ unflexibel ist.

niklas-KIM hat geschrieben:

Als Randbemerkung, dass bei Windows die Maus auch dann noch funktioniert wenn der PC aus dem letzte Loch pfeift ist zwar ein nettes feature, aber eigentlich das Ergebnis einer Designschäche. Und zwar sind in Windows große Teile des Window und GUI Systems direkt in den Kernel eingebaut, man mag es finden wie man will, aber dies ist einer der Gründe warum ein Windows System nur schwer genug abgespeckt werden kann embedded eingesetzt zu werden und das es relativ unflexibel ist.

Das kann man kaum eine Designschwäche nennen. Windows war von Anfang an als Desktopsystem gedacht, und als solches ist es eine große Stärke wenn die grafische Oberfläche direkt im Kernel ist. Ich wünschte, das wäre auch bei Linux eine Option und man müsste sich nicht immer mit diesem leidigen X Server herumschlagen (welchen ich mal frei heraus als "Designschwäche" brandmarken möchte).

Bei mir friert da nichts ein, ich habe aber auch die /etc/security/limits.conf etwas optimiert. Ich hab gerade keine Lust, alles auf oob zurück zu stellen, aber ich bezweifele, dass der Kernel bei dir abgestürzt ist. Der XServer ist es sicher und wie man damit umgeht s. den Wikiartikel "Notfall" für näheres. Kannst auch einfach mal im syslog nach "Kernel panic" suchen, dann wäre er wirklich abgestürzt.

@gflash
Wenn man den XServer einfach im Kernelspace laufen lässt, wird er auch nicht besser. Windows ist nicht monolithisch, die können sich sowas vll erlauben, aber für Linux wäre es ganz bitter. Darüber hinaus ist es auch übelst unsauber, wenn jeder Pups-Benutzer direkt an Kernel muss um z.B. seine Auflösung zu ändern. Dir mag der Xserver nicht gefallen, aber damit dass er nicht im Kernel ist, haben deine Probleme nichts zu tun.

Das gleiche ist mir mal passiert als ich im Firefox einen Urlaubsbericht mit sehr sehr vielen Fotos geöffnet habe. Der RAM war irgendwann voll, dann wurde noch ausgelagert und als der Swap voll war ging fast gar nichts mehr.

gflash hat geschrieben:

Das kann man kaum eine Designschwäche nennen. Windows war von Anfang an als Desktopsystem gedacht, und als solches ist es eine große Stärke wenn die grafische Oberfläche direkt im Kernel ist. Ich wünschte, das wäre auch bei Linux eine Option und man müsste sich nicht immer mit diesem leidigen X Server herumschlagen (welchen ich mal frei heraus als "Designschwäche" brandmarken möchte).

X ist vieleicht kein Wunder an Geschwindigkeit, diese Probleme liegen aber zum größten Teil in seiner Stiefmütterlichen Weiterentwicklung unter XFree86. X.org ist gerade auf dem besten Weg die Vorteile von X (Netzwerktransparenz, OS- bzw. Kernelunabhängigkeit, Flexibilität, etc.) mit der Benutzerfreundlichkeit (Sprich Plug'n'Play) auf einem Desktop-System zu verbinden. Das hat aber überhaupt gar nichts damit zu tun, ob die GUI nun um Kernel läuft oder nicht. Und GUIs im Kernel sind ein Designfehler.

Nur nochmal zur Verdeutlichung, hat Quake4 z.B. etwas im Kernel zu suchen? Ich denke, das würden viele verneinen. Ein moderner XServer wäre davon nicht sehr weit weg. (2D/3D Thematik lasse ich mal weg)