PureBoard

4.31 x64 win:
Windows friert komplett ein, lediglich der Mauszeiger läßt sich noch bewegen

x64 lin:
Linux friert ein

Wundert dich das denn ?

Mit x64 hat jeder Prozess 8TB virtuellen Addressspace (zumindest in Windows), und ihr habt da ein Programm das soviel Speicher verlangt wie es nur kriegen kann. Das das OS bei dem Versuch soviel Speicher zur Verfügung zu stellen an Resourcenmangel verreckt ist doch ganz normal.

x86 Win:
keine Probleme

x86 Lin:
Das Programm stürtzt hier ab, aber erst auf der Debug-Zeile. Und auch das ist nicht sehr verwunderlich, denn der Prozess hat wohl nichtmal mehr genug Speicher für den String selber.

Der Test ist auch ziemlich unsinning. Wer müllt sich denn schon den Speicher mit 1997876 1000-Byte Blöcken voll?

freak hat geschrieben: Der Test ist auch ziemlich unsinning. Wer müllt sich denn schon den Speicher mit 1997876 1000-Byte Blöcken voll?

Stimmt, aber 200 10 - MB Blöcke/ 20 100 MB - Blöcke würden auch denselben Effekt erzielen und währen schon etwas realistischer. Ein paar große Dateien gleichzeitig im Speicher und schon ists passiert. Drum hätt ichs halt probiert und würde in solchen Fällen eben immer den Pointer gegen 0 prüfen und sagen "Halt, zuviel, schmeiß erst was anderes aus dem Speicher".

Gruß, Alex

> Wundert dich das denn ?
Eigentlich schon , hätte erwartet das Windows die Anforderung vorher
ablehnt, bevor es verreckt

> Der Test ist auch ziemlich unsinning. Wer müllt sich denn schon den Speicher mit 1997876 1000-Byte Blöcken voll?
Das stimmt schon, aber zum testen mache ich alle Schandtaten mit

cxAlex hat geschrieben:

freak hat geschrieben: Der Test ist auch ziemlich unsinning. Wer müllt sich denn schon den Speicher mit 1997876 1000-Byte Blöcken voll?

Stimmt, aber 200 10 - MB Blöcke/ 20 100 MB - Blöcke würden auch denselben Effekt erzielen und währen schon etwas realistischer. Ein paar große Dateien gleichzeitig im Speicher und schon ists passiert. Drum hätt ichs halt probiert und würde in solchen Fällen eben immer den Pointer gegen 0 prüfen und sagen "Halt, zuviel, schmeiß erst was anderes aus dem Speicher".

Gruß, Alex

Nein, der Effekt ist nicht der selbe: Wenn die Anfrage nach 10MB fehlschlägt hat man in der Regel immernoch ein paar Byte zur Verfügung um eine Fehlermeldung zusammen zu bauen. Wenn aber der Platz bis zum letzten Byte voll ist, dann hat so ziemlich jedes Programm ein Problem, weil mann dann nichtmal mehr einen Requester aufmachen kann um dem User das mitzuteilen.

Pointer gegen 0 prüfen sollte man natürlich trotzdem immer machen, aber wenn man sich an der absoluten Grenze des Möglichen befindet hat man weit mehr Probleme als nur dieses eine fehlgeschlagene AllocateMemory()

ts-soft hat geschrieben:> Wundert dich das denn ?
Eigentlich schon , hätte erwartet das Windows die Anforderung vorher
ablehnt, bevor es verreckt

Große Teile des Betriebssystens sind ja auch nur normale Prozesse. Warum sollten die mehr Recht auf Speicher haben als das Testprogramm ?

Seid doch froh das ihr nur einen IMA bekommt. Bei mir stürzt Windows komplett ab und gibt einen Bluescreen aus: "DRIVER_IRQL_NOT_LESS_Or_EQUAL". Das Problem tritt bei mir aber auch bei Battlefield Heroes auf, sonst jedoch nirgendwo.

[b]Edit: [/b] Ich hab den Code gerade noch unter Linux (OpenSuse 11) getestet. Hier bekomme ich auch den von den anderen gemeldeten IMA-Fehler bei Debug.

[b]Edit 2 [/b] Jetzt läuft es. Nachdem ich den Neustart für den Bluescreen deaktiviert habe. Läuft Problemlos, ohne IMA unter Windows XP.

kswb73 hat geschrieben:Seid doch froh das ihr nur einen IMA bekommt. Bei mir stürzt Windows komplett ab und gibt einen Bluescreen aus: "DRIVER_IRQL_NOT_LESS_Or_EQUAL". Das Problem tritt bei mir aber auch bei Battlefield Heroes auf, sonst jedoch nirgendwo.

Das hört sich aber nach einem Hardwareproblem an. Könnte auch ein
Treiber sein.