Ein paar Zeilen Code legen einen Mac lahm?

[little_skunk]

Es gibt in der Softwareentwicklung mehr zu beachten als nur die Fehlermeldungen von der Entwicklungsumgebung. Eine Endlosschleife wird nicht formal richtig nur weil die Entwicklungsumgebung den Fehler nicht erkennt.

Interessant finde ich halt eher einfach die 2GB Grenze, die unter Windows zu einem Absturz führt.

Was ist daran interessant? Das hatten wir bereits geklärt. Ich fasse nochmal kurz zusammen.
1.) Bei 32Bit gibt es Standardmäßig 4GB Speicher. 2GB sind für den Kernel vorgesehen. Die restlichen 2GB können frei belegt werden. Man kann die Aufteilung der 4GB auch verändern. Zum Beispiel 1GB für den Kernel. Dann bleiben 3GB zur freien Verfügung. Was der Kernel macht wenn sein GB voll ist, kann sich denke ich jeder ausmahlen. Wer mehr Speicher möchte, kann natürlich auch mit 64Bit arbeiten. Alles nur eine Frage der Compiler Konfiguration.
2.) Die Funktion New reagiert je nach Compilerversion unterschiedlich auf vollen Speicher. Entweder Null Referenzen oder eine Exception. Darauf muss man entsprechend reagieren und das Programm geordnet Beenden. Im Beispiel ist das nicht der Fall und genau da liegt der Fehler. Was danach passiert sind nur noch Folgefehler, die sich der Programmierer auf seine Rechnung schreiben kann.

Ist der Einwurf von little_Skunk hierbei vielleicht des Rätsels Lösung?

Nein ist er nicht. Mein Einwurf bezog sich auf die Idee den Speicher mit Rekursion voll machen zu wollen. Die Idee kam auf, weil bei Rekursion die Pointer auf die Speicheradressen erhalten bleiben und nicht so wie beim Beispiel verlohren gehen. Nun hat Rekursion aber die dumme Angewohnheit, dass im Stack die Rücksprungadresse gespeichert werden muss. Damit bekommt man eher den Stack als den Speicher voll. Außerdem ändert der fehlende Pointer auf den belegten Speicher nichts am Verhalten der Funktion New.

 

[MrX13415]

Hi,

erstmal sorry, das ich diesen alten Thread wieder aufwecke xD

Mich hat das Thema sehr interessiert und vorallem das verhalten des MAC ist interesant.
Wie bei vielen anderen hier war für mich auch nicht ganz klar was Windows macht, wenn der Ram voll ist.
Also hab ich auch ein solches Programm geschrieben (kann ich bei interesse anhängen). Für Windows XP bis Windows 8.1, 32 und 64 Bit.
Getestet hab ich auf Windows XP 32 und 64 Bit und Windows 8.1 64 Bit mit deaktivierter Auslagernungsdatei.
Bei 32 Bit, hab ich das ganze einmal mit 8 GB Ram und einmal mit 1 GB RAM getestet. Bei 64 Bit mit 8 GB RAM.

In allen Fällen (auch unter Windows XP) hat Windows bei 90% RAM Auslastung die Speicher intensivsten Programme beendet.
Unter Windows XP 32 Bit und mehr als 2 GB RAM wurde das Pogramm bei 2 GB Auslastung des Programms beendet bzw. wenn es mehrmals ausgeführt wurde, ebenso bei 90%.
Bei Windows 8 (bei Win 7 und Vista wahrscheinlich auch) wird man mit einer Meldung auf das Programm und das es beendet wird hingeweisen.

Ich hab leider kein MAC zum testen da, jedoch ist das schon ein unschönes verhalten, wenn der MAC einfach abstürtzt. Definitiv ist da noch Nachholbedarf!
Es lässt sich jetzt darüber streiten, ob das Programm fehlerhaft ist oder nicht, aber ich denke nicht, das ein Programmierer eines Speichernintensiven Programms auch noch das Speichermanagment des Sysms übernehmen muss bzw aufpassen muss, das das System wegen RAM abstürtzt. RAM ist ja zum Auslasten da, was nützt einem 8 GB RAM wenn man immer nur 4 GB davon verwendet?

~MrX13415

 

[little_skunk]

Es lässt sich jetzt darüber streiten, ob das Programm fehlerhaft ist oder nicht, aber ich denke nicht, das ein Programmierer eines Speichernintensiven Programms auch noch das Speichermanagment des Sysms übernehmen muss bzw aufpassen muss, das das System wegen RAM abstürtzt.

Da muss man sich nicht streiten. Es geht nicht um das Speichermanagment. Es geht schlicht und einfach um die Tatsache, dass die Funktion New eine Exception werfen kann. Was steht doch gleich im Lehrbuch zum Thema Exception? Einfach ignorieren und weitermachen? Irgendjemand wird sich schon darum kümmern und eraten was meine Funktion gerade machen wollte? Das habe ich noch etwas anders in Erinnerung...

RAM ist ja zum Auslasten da, was nützt einem 8 GB RAM wenn man immer nur 4 GB davon verwendet?

Der Unterschied zwischen 32 und 64bit ist dir bekannt?

 

[pointX]

dass die Funktion New eine Exception werfen kann.?

Wirft denn die Funktion "new" in dem Fall unter OSX eine Exception ?

Exceptions werden doch (wenn nicht durch catch behandelt) an die aufrufende Funktion "nach oben" weitergereicht.
Hier würde ja eine Exception in der main()-Methode auftreten, die nicht behandelt wird, also an das Betriebssystem weitergereicht wird.
Sollte das Betriebssystem dann nicht eine Fehlermeldung bringen "im prozess xy ist eine unbehandelte Exception aufgetreten. Prozess beenden / ignorieren ?" ?
Das jedenfalls würde ich vom Betriebssystem (jedenfalls von Windows/OSX/Linux) schon erwarten, dass es unbehandelte Exceptions abfängt und dann geordnet weitermacht.

Oder wird die Exception erst dann geworfen, wenn der Speicher eh schon voll ist und das Betriebssystem selbst keinen speicher mehr bekommt, um diese Exception überhaupt zu verarbeiten & eine Fehlermeldung darzustellen und daraufhin einfriert ?
Wenn ja dann würde aber eine Fehlerbehandlung im Beispiel von "sg-1" garnichts bringen, da selbst mit Fehlerbehandlung durch den Programmierer der speicher vollaufen würde und das System einfriert.

Ist also vllt. der Fehler, dass OSX hier einfach "bis zum letzten byte" speicher freigibt, und dann selbst nicht mehr in der Lage ist die Exception (ausgelöst durch new weil kein Speicher mehr frei ist) zu verarbeiten ?
Oder habe ich irgendwo einen Denkfehler ?
Kann´s leider mangels Apple-Rechner nicht selbst testen

PS:

Was steht doch gleich im Lehrbuch zum Thema Exception? Einfach ignorieren und weitermachen?

In Java fällt z.B. die nullpointer-dereferenzierung genau darunter ("unchecked Exceptions"). Man kann sie behandeln, muss aber nicht.
Beim auftreten wird sich schon die JRE / Betriebssystem drum kümmern. Also "einfach ignorieren" trifft zumindest unter Java für die "unchecked Exceptions" schon zu

 

[little_skunk]

Wirft denn die Funktion "new" in dem Fall unter OSX eine Exception ?

Das ist abhängig von der Compiler Version. Bei ältere Compiler liefert "new" eine Null Referenz. Stellt sich die Frage wie sich OSX mit neuem Compilter verhalten hätte.

Exceptions werden doch (wenn nicht durch catch behandelt) an die aufrufende Funktion "nach oben" weitergereicht.
Hier würde ja eine Exception in der main()-Methode auftreten, die nicht behandelt wird, also an das Betriebssystem weitergereicht wird.
Sollte das Betriebssystem dann nicht eine Fehlermeldung bringen "im prozess xy ist eine unbehandelte Exception aufgetreten. Prozess beenden / ignorieren ?" ?
Das jedenfalls würde ich vom Betriebssystem (jedenfalls von Windows/OSX/Linux) schon erwarten, dass es unbehandelte Exceptions abfängt und dann geordnet weitermacht.

Bei älteren Compiler Versionen wirft die Funktion new keine Exception und damit ist die Theorie nicht anwendbar.
Ich halte das Beispiel weiterhin für sinnfrei. Wenn ich als Ziel habe das Betriebssystem abschmieren zu lassen, dann bekomme ich das auch problemlos mit Windows hin. Wenn das Ziel ein halbwegs ordentliches (Test)Programm ist, dann sollte man zumindest die in diesem Fall unausweichliche Exception bzw Null Referenz behandeln und das Programm geordnet beenden.

Oder wird die Exception erst dann geworfen, wenn der Speicher eh schon voll ist und das Betriebssystem selbst keinen speicher mehr bekommt, um diese Exception überhaupt zu verarbeiten & eine Fehlermeldung darzustellen und daraufhin einfriert ?
Wenn ja dann würde aber eine Fehlerbehandlung im Beispiel von "sg-1" garnichts bringen, da selbst mit Fehlerbehandlung durch den Programmierer der speicher vollaufen würde und das System einfriert.

Gute Frage. Ich hätte behauptet, dass das über den Stacktrace läuft. Genau weiß ich das aber nicht. Da er im Falle von Windows mit vermutlich neuerer Compiler Version eine Exception gesehen hat, muss das mit vollem Speicher anscheinend noch möglich sein.

So oder so würde eine interne Fehlerbehandlung wegen einem weiteren Programmierfehler nicht viel helfen. Was bringt einem eine out of memory exception wenn man mangels pointer den Speicher sowieso nicht freigeben kann?

Ist also vllt. der Fehler, dass OSX hier einfach "bis zum letzten byte" speicher freigibt, und dann selbst nicht mehr in der Lage ist die Exception (ausgelöst durch new weil kein Speicher mehr frei ist) zu verarbeiten ?
Oder habe ich irgendwo einen Denkfehler ?
Kann´s leider mangels Apple-Rechner nicht selbst testen

Ich hab hier (zum Glück) auch keinen Apple Rechner. Dazu kann ich nicht viel sagen.
Bisher ist hier im Tread außer Apple Bashing aber nichts vernüftiges passiert. Interessant würde es erst werden wenn das Testprogramm fleißig Speicher belegt, sich die Pointer merkt und bei der Exception den Speicher komplett wieder frei gibt. Das wäre ein realistisches Testprogramm. Sollte OSX dann immernoch abstürtzen, nehme ich alles zurück und behaupte das Gegenteil.

Neuere Programmiersprachen verzichten nicht ohne Grund auf Pointer. Ich kann mich noch an meine C++ Testprogramme unter Windows erinnern. Ein Bluescreen war sehr einfach möglich. Man muss nur genau das machen wovor einem das Lehrbuch warnt. Ich war aber zu keinem Zeitpunkt so blöd desswegen ein Windows Bash Tread aufzumachen. Wenn ich schon gegen jede Regel im Umgang mit Pointern verstoße, dann mache ich meine Dummheit doch nicht noch öffentlich...

In Java fällt z.B. die nullpointer-dereferenzierung genau darunter ("unchecked Exceptions"). Man kann sie behandeln, muss aber nicht.
Beim auftreten wird sich schon die JRE / Betriebssystem drum kümmern. Also "einfach ignorieren" trifft zumindest unter Java für die "unchecked Exceptions" schon zu

Erstmal ist Java das absolute Gegenteil von C++. Lässt sich schlecht vergleichen. Die Unterscheidung zwischen checked und unchecked Exception gibt es in C++ nicht.

Eine unchecked Exception sind Fehler des Programmierers. Einprogrammierte Bugs wenn man so will. Würde man sie abfangen, würde man den Fehler nur verstecken. Häufig werden solche Fehler auch gleich von der Entwicklungsumgebung als Warning oder sogar als Error ausgegeben (je nach Einstellung). Alle anderen Fehler sollten in der Theorie checked Exception sein. Ist in der Praxist aber etwas schwierig umzusetzen.
Unter Java kann man sich diesen Luxus leisten. Unter C++ hat man keine Runtime mit Carbage Collector als Absicherung zwischen dem eigenen Quellcode und der Betriebssystem.

 

[pointX]

Das ist abhängig von der Compiler Version. Bei ältere Compiler liefert "new" eine Null Referenz. Stellt sich die Frage wie sich OSX mit neuem Compilter verhalten hätte.
Bei älteren Compiler Versionen wirft die Funktion new keine Exception und damit ist die Theorie nicht anwendbar.

Hm stimmt, daran habe ich garnicht gedacht.
Aber dann würde doch einfach fortlaufend versucht, neuen Speicher zu belegen, was mit einem nullpointer beantwortet wird.
Ein unberechtigeter Nullpointer-Zugriff findet ja nicht statt. Eigentlich dann auch kein Grund, für das Betriebssystem abzuschmieren, oder ? Erzeugt halt viel CPU-Last & Speicherzugriff
Wäre wirklich interessant, ob z.B. beim ersten nullpointer ein cin auf eine am anfang angelegte variable / speicher wieder freigeben noch funktioniert

Bisher ist hier im Tread außer Apple Bashing aber nichts vernüftiges passiert.

Ja das stimmt, leider. Aber das Problem an sich ist schon interessant, da mit Exception & Speicherallokation gleich 2 wichtige Dinge von C/C++ drin sind & natürlich die Frage wie und warum ein Betriebssystem (in Extremsituation) darauf reagiert.
Wäre schön wenn das jmd. testen könnte, was wirklich passiert:
- wird eine Exception geworfen oder einfach ein null-pointer zurückgegeben (bei welcher Compiler-Version) ?
- wenn eine Exception geworfen wird: warum kann sie durch das System nicht behandelt werden ?
- wenn ein null-pointer zurückgegeben wird, und der Speicher wieder freigegeben wird, läuft das System dann weiter ?

Ein Bluescreen war sehr einfach möglich. Man muss nur genau das machen wovor einem das Lehrbuch warnt.

Mein Prof. sagte immer "mit C/C++ rennt man mit dem offenen Messer durch den PC"

 

[jdl]

Wirft denn die Funktion "new" in dem Fall unter OSX eine Exception?

Die Funktion new wirft in C++ nur in Zusammenhang mit Referenzen eine Exception, sonst wird ein Nullpointer zurückgegeben.

 

[Radeon HD 5870]

Der Mac macht alles richtig. Ein Betriebsystem sollte niemals ein Prozess beenden nur weil er zu viel Speicher braucht. Das bei einigen das Programm bei Windows abschmiert liegt vermutlich nur daran das das Programm nicht in 64bit kompiliert wurde.

Ich habe selber schon Programme geschrieben die über 20GB Speicher "gebucht" haben. Die meisten Betriebsysteme "freezen" dann quasi, wenn mann lange genug wartet (möglicherweise Jahre) sollte aber dennoch das System reagieren, also wenn mann Firefox oder so startet.

An alle Windows 8 Hater, Windows 8 bleibt sehr stabil wenn extrem viel Speicher benutzt wird. Das System reagiert also noch halbwegs.