Out of Memory Exception?

[Der schöne Günther]

Wenn dieser Fehler auftritt, ist es in der Regel zu spät.
Siehe auch:
https://stackoverflow.com/q/14975346

[himitsu]

Zitat von Der schöne Günther:

ist es in der Regel zu spät.

Es kommt drauf an, wie man darauf reagiert.

z.B. ein viel zu großes Bild in eine "optionale" Vorschaukomponente zu laden, also einmal das Bild in den Speicher laden und der Komponente zuweisen.
und dann, wenn es nicht ging, wieder entladen (falls nötig) und ein kleines Fehlerbildchen mit Hinweis an anzeigen.

Ob es nun knallt, weil die Datei nicht geladen werden kann (existiert nicht oder defekt, bzw. ungültiges Format) oder ob es beim Anzeigen knallt, macht grundsätzlich keinen Unterschied.



Gut, man kann für eine Aktion auch einfach versuchen "viel Speicher" zu reservieren
und wenn es nicht geht, dann mit Weniger weitermachen,
aber natürlich könnte man hier auch vorher nachsehn, ob genug Speicher vorhanden ist, ABER auch das hat einen Haken -> fragmentierten Speicher.

32 Bit-Windows-Programm ... versuche dort mal einen 1 GB-Speicher-Block zu reservieren.
selbst wenn im Programm noch über 1 GB frei sind, muß es nicht sein, dass auch ein "zusammenhängender" Block verfügbar ist.

[Amateurprofi]

Zitat von himitsu:

32 Bit-Windows-Programm ... versuche dort mal einen 1 GB-Speicher-Block zu reservieren.

Bei mir kein Problem:
32 Bit-Windows-Programm 1,601,027,154 Bytes in einem Block reserviert.
Hat noch nie Probleme gemacht.
Siehe anhängendes Bild ganz unten, drittes Panel in der Statusleiste

[QuickAndDirty]

EoutOffmemory bzw. Systemfehler 8
kann auch passieren wenn die Windows Atomtabelle voll ist!
lässt sich provuzieren wenn mein ein windows mit endlicher Atomtabelle verwendet und
einen Dienst programmiert der viele instanzen von einem
Programm mit Twincontrols und anderen resourcen die Handle brauchen startet und kontrolliert.

Diensten stehen nur sehr wenige Heap-Resourcen in der Atomtabelle zu.
Aber man kann die Größe der Atomtabelle anpassen, in der Registry...

Code:

HKLM\System\CurrentControlSet\Control\Session Manager\SubSystem\windows

Die zeichen kette in einen Texteditor kopieren und folgenden text suchen und anpassen

Code:

SharedSection=1024,20480,768

Die Zahlen hinter SharedSection können je nach Windows version andere sein.

Code:

SharedSection=x,y,z

x maximale größe des systemweiten Heap in Kilobytes
y Größe jedes Desktop-Heaps. Das sollte sich in modernen Windows versionen automatisch passend erhöhen...
z Größe jedes Desktop-Heaps für nicht interaktive Window-Instanzen aka Dienste. Die kann zu klein sein. Leider betrifft es dann immer alle Dienste auch wenn nur einer diese Änderung braucht.



Und wenn man Delphi 2007 verwendet dann leacked Controls.Pas auch noch mit atomtabellen einträge die nicht mehr wieder gewonnen werden können...
Wenn man so ein programm immer wieder startet und beendet dann friert irgenwann dein Windows ein.

Delphi-Quellcode:

//D2007 Controls.pas
ControlAtomString := Format('ControlOfs%.8X%.8X', [HInstance, GetCurrentThreadID]);//es war irgendwas dynamisches diese zeile ist aus D XE11 aber es war etwas ähnliches in d2007
RM_GetObjectInstance := RegisterWindowMessage(PChar(ControlAtomString));// dieser eintrag wird NICHT aufgeräumt wenn das programm beendet wird.

Delphi-Quellcode:

//D XE 11.x Controls.pas
RM_GetObjectInstance := RegisterWindowMessage(PChar('DelphiRM_GetObjectInstance'));// dieser Eintrag führt glaube ich nur zu einem einmaligen leak.

[himitsu]

Zitat von Amateurprofi:

Bei mir kein Problem

Lass dein Programm mal eine Weile laufen.

Effektiv, kann ich sage, also in Bezug auf unser Programm und einige Andere, dass durchschnittlich vorwiegend nur 0,7 GB zusammenhängend verfügbar sind.
- Delphi XE (und 11.3)
- damals noch ohne aktive 4-GB-Option
- DevExpress uns Anderes
- Laufzeitpackages
- 200 MB laut Taskmanager belegt



Einmal liegen die DLLs und BPLs im RAM verteilt,
dann gibt FastMM nicht jeden Speicher sofort wieder frei,
über die Laufzeit verteilt sich der Speicher auch mehr im RAM
und Dank dem neuerdings im Delphi aktiven ASLR

ohne ASLR und mit aktivem IMAGE_FILE_LARGE_ADDRESS_AWARE könnte man davon ausgehn, dass die oberen 2 GB lange verfügbar sind, da sich fast alles mit Vorliebe in den ersten 2 GB tummelt.

[Amateurprofi]

Zitat von himitsu:

Lass dein Programm mal eine Weile laufen.

Stundenlang, auch mal den ganzen Tag lang.
Bisher nie Probleme, auch wenn ich die befürchtet hatte.

[mwilms]

Danke für die zahlreichen Antworten.

Ich bekomme eine EOutOfMemory Exception bereits bei einem Block von 250 MB. Im Task Manager werden 6 GB freier Speicher angezeigt.

Kann man Windows dazu bewegen, Speicher auf die Festplatte auszulagern oder anderweitig freien Speicher in einem Block zur Verfügung zu stellen? Ich dachte das Hardware-mäßige Paging des Prozessors von 4096 KB großen Blöcken ermöglicht so ewtas (logische Adressierung von RAM Speicher).

mwilms

[Uwe Raabe]

Die Frage ist eher, wieviel Speicher der Prozess zur Verfügung hat. Bei 32-Bit Programmen sind das erstmal nur 2GB gesamt. Je nach aktueller Belegung und Fragmentierung kann das auch bei überschaubaren Blöcken schon mal eng werden. Wenn dann noch Memory-Leaks dazu kommen ist es schnell mal zu viel.

[himitsu]

Hab gesten mal bissl rumgespielt.

Das IMAGE_FILE_LARGE_ADDRESS_AWARE jeweils ein-/auskommentiert für 4 GB oder die normalen 2 GB.

* DLLs liegen gern am Ende der 2 GB
* FastMM reserviert SmallBlocks gern am Anfang (unten im Speicher)
* LargeBlocks werden gern am Ende reserviert (oben im Speicher)
* wo die MediumBlocks des FastMM liegen, hab ich vergessen nachzusehn

* denn beim VirtualAlloc kann man angeben, ob "lieber" oben oder unten (MEM_TOP_DOWN)

Aber eigentlich sollten, mit Delphi 11.3 und unter Windows 11 (bzw. im Win10 aktivieren),
wenn ASLR im Windows und in der EXE aktiv ist, die DLLs doch etwas mehr verteilt sein?