Out of Memory Exception?

[mwilms]

Hallo,

gibt es eine "Out of memory" Exception, die man abfangen kann, um der Meldung "Zu wenig Arbeitsspeicher" vorzubeugen?

Vielen Dank

mwilms

[Delphi.Narium]

Zitat:

Zitat von Delphihilfe

EOutOfMemory

EOutOfMemory ist die Exception-Klasse für fehlgeschlagene Versuche, Speicher zuzuweisen.

Delphi-Quellcode:

begin
  try
    ...
  except
    on e : EOutOfMemory do begin
      // Speicherriegel kaufen ;-)
    end;
  end;
end;

[Sinspin]

Ja, so wie jede andere Exception auch.
Allerdings ist EOutOfMemory etwas recht ungewöhnliches. Was machst Du denn bevor Du die Meldung bekommst?

[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:

Zitat von Der schöne Günther (Beitrag 1525135)

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:

Zitat von himitsu (Beitrag 1525138)

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:

Zitat von Amateurprofi (Beitrag 1525143)

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:

Zitat von himitsu (Beitrag 1525150)

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