GetMem mit Delphi 2010 unter Windows 8

[maxbafh]

Habe das Problem, das GetMem unter Windows 8 mit Delphi 2010 compiliert bei 1GB sagt out of memory. Dies passiert aber nur für den selben Speicherbereich. Wenn ich einen zweiten Speicherbereich alloziere hab ich as Problem nicht, dann kann ich weiter 1GB allozieren.

Kennt ihr dafür einen Work-Arround. Danke für eure Hilfe.

maxbafh

[himitsu]

Weil dein Programm nunmal nur 2 GB an virtuellem RAM zur Verfügung hat.
Dann liegen in dem Speicher "verteilt" bereits die EXE, DLLs und die sonstigen reservierten Speicherblöcke usw.

Und nun versuch mal in diese "fragmentierten" 2 GB noch einen "zusammenhängenden" 1 GB-Block zu finden.


Nach meiner Erfahrung wird es ab 500 MB immer schwerer etwas zu finden und wenn kein zusammenhängender Block mehr existiert, welcher mindestens die 1 GB aufnehmen kann, dann knallt es eben.
Im Extremfall reichen nur 2x je 1 Byte gut verteilt, um deinen 1 GB-Block im verfügbaren 2 GB-Bereich zu blockieren.


Lösungen:
* Überlegen ob man überhaupt 1 GB an Arbeitspeicher benötigt und versuchen mit weniger auszukommen
* Aufteilen -> mehrere kleinere Blöcke, die zusammen 1 GB beinhalten
* Auslagern -> z.B. MMF (MemoryMappedFiles), wovon nur ein aktuell benötigter kleiner Teil in deinen virtuellen RAM gemappt wird. (und der Rest kann entweder in einer Datei oder im physischen RAM rumliegen)
* Ein 64-Bit-Programm schreiben ... das hat einen größeren virtuellen RAM, womit die Fragmentierung nicht so schnell zum Problem wird.
* ...

[maxbafh]

Das interessante ist aber, das es bis Windows 7 problemlos klappt aber unter Windows 8 knallt es. Das ist der einzige Unterschied zwischen den beiden Systemen ;-)

Wie soll ich sonst ein Bild laden, wenn ich es nicht komplett in den Memory legen kann? Physikalische System-Memory steht ja genug zur Verfügung.

Was noch dazu zu sagen ist mit XE5 kompiliert funktioniert der Source. Ich will nur meine alte App nicht auf XE5 umändern, da sie eigentlich EOL ist.

[himitsu]

Unterschiede:
Die DLLs werden nicht immer an der selben Stelle geladen, und es gibt sogar andere DLLs in beiden Systemen. (es gibt sogar ein Sicherheitssystem, welches die DLLs immer mal wieder verschiebt, so daß es Hacker/Viren schwerer haben, über eine hardgecodete Adresse einfach so irgendwas böses zu machen.
Auch GetMem un Konsorten geben nicht immer die selben Speicherpositionen zurück, bei jedem Programmstart, womit alle anderen Speicherblöcke auch gerne mal anders erteilt sind.

Fazit: Du hattest Glück, daß es nicht vorher schon ab und an mal geknallt hat.



PS: Hatte meinen letzte Beitrag zwischenzeitlich nochmal erweitert.

[Bernhard Geyer]

Zitat:

Zitat von maxbafh (Beitrag 1272887)

Das interessante ist aber, das es bis Windows 7 problemlos klappt aber unter Windows 8 knallt es. Das ist der einzige Unterschied zwischen den beiden Systemen ;-)

Einmal Win7, einmal Win8. Dieser "einzige" Unterschied ist das du 2 vollkommen unterschiedliche System vergleicht bei denen keine geladene Systemdatei gleich ist.

Zitat:

Zitat von maxbafh (Beitrag 1272887)

Was noch dazu zu sagen ist mit XE5 kompiliert funktioniert der Source.

Evtl. als 64-Bit Anwendung kompiliert?

[himitsu]

Zitat:

Zitat von maxbafh (Beitrag 1272887)

Was noch dazu zu sagen ist mit XE5 kompiliert funktioniert der Source.

andere RTL/VCL = andere Dinge im RAM

[maxbafh]

Zitat:

Zitat von maxbafh (Beitrag 1272887)

Was noch dazu zu sagen ist mit XE5 kompiliert funktioniert der Source.

Evtl. als 64-Bit Anwendung kompiliert?[/QUOTE]

Da klappt es in beiden Varianten sowohl als 64bit als auch als 32bit Version.

[himitsu]

Wie gesagt, ein einziges Byte an anderer/neuer Stelle im RAM und schon kann es das gewesen sein.

Mit FastMM kann man sich gern eine Memory-Map von seinem Programm generieren lassen und sieht dann wie/wo der Speicher belegt ist.

Zitat:

Zitat von maxbafh (Beitrag 1272896)

Da klappt es in beiden Varianten sowohl als 64bit als auch als 32bit Version.

Warum es mit 64 Bit klappt, hatte ich ja bereits geschrieben.


Nimm dir einen der abschließenden Punkte von Post #2 und schon ist das Problem behoben. :roll:

[maxbafh]

Alles zusammen eine nette Idee, kann ich jedoch nicht in der Praxis umsetzen. Nicht weil ich es nicht kann, sondern weil es nicht klappt.

*) MMF - Komprimiertes Bild ist 500MB auf der HDD => unkomprimiert > 1GB brauch es aber unkomprimiert damit ich damit arbeiten kann - MMF kann ich aber nur 1:1 Mappen und nicht komprimiert auf unkomprimiert.

*) Aufteilen - ja ein gesamtes Image kann ich nicht aufteilen auf zwei Speicherbereiche, das braucht einen zusammenhängenden Memory.

*) Mit weniger Aus zu kommen - gut gemeint, schlecht in der Umsetzung.

*) 64bit App - ja für die neue Version, nur nicht für die EOL Version mehr.

[jbg]

Bei einem 32-Bit Programm kann man noch das Linker-Flag IMAGE_FILE_LARGE_ADDRESS_AWARE setzen. Dadurch erhöht sich der Adressraum von 2 GB auf 3GB. Vorraussetzung ist ein 64-Bit Windows oder ein 32-Bit Windows mit dem /3GB Boot-Schalter.

Das Programm und all seine Komponenten und DLLs müssen dann aber auch mit Pointern größer 2 GB richtig umgehen können, was z.B. bei "Integer(P1) - Integer(P2)" nicht der Fall ist (Overflow-Exception).

Folgende Zeile in die DPR Datei einfügen

Delphi-Quellcode:

program MyApp;

{$SetPeFlags $20} // IMAGE_FILE_LARGE_ADDRESS_AWARE

uses
  Forms,
...