Speicherreservierung rückführen

Hi Leute,

ich habe eine WIN32 - Anwendung vor mir liegen, welches durch irgendeinen Fehler meiner Meinung nach viel Dump auf dem Memory erzeugt.
(keine Speicherlöcher, eher falsche Algorithmen [Reservieren <-> Aufräumen])
Nun ich will euch durch meine eigene Meinung nicht zu sehr irritieren.

Das grundlegende Problem:
Während der Programmausführung steigt der RAM bis auf 2,6GB (von max 4GB -> 2^32Byte)
-- Zusatzinfo: kurz davor war er auf ~3,8GB und ging runter auf 2,6GB (stabil anhaltend) --
(zeigt mir der Prozess Explorer zumindest so an)...
Jedoch haut mir meine Anwendung einen Fehler raus, dass angeblich
kein Speicher mehr vorhanden ist.

Ich vermute dass keine 1,4GB (4GB - 2,6GB) frei sind wie der Prozess-Explorer mir sagt,
sondern die 3,8GB irgendwas damit zu tun haben, dass am Ende kein Speicher mehr frei ist.

Was tun ist die Frage?
Hatte schon jemand ähnliche Probleme?
Gibts ein Tool um die Speicherreservierung rückführen zu können?
(=> Übersicht über die Funktionen die dauernt Speicher fressen, damit ich weiß wo ich anfange)
Irgendwelche Debugging Tipps?

Es sollte erwähnt werden, dass es sich um eine große Anwendung mit vielen .cpp Dateien handelt und es genau aus diesem Grund
nicht leicht ist nachzuvollziehen woher der Fehler kommt.

Greece Nexx

volkard

Nexx schrieb:

(keine Speicherlöcher, eher falsche Algorithmen [Reservieren <-> Aufräumen])

Schade. Speicherlöcher aus Deinem Quellcode zu finden wären einfach mit einem Debug Heap.

Klingt es realistisch, daß 2.6G benötigt werden? Falls ja, kanns auch daran liegen, daß nach einiger Zeit einfach nicht mehr sagen wie mal 200k *am Stück* frei sind und jemand 200k allokieren will. Und 2.6G sind schon recht viel für ein 32-bittiges Windows. Nicht alle würden das überhaupt einer Anwendung geben können, hängt zum Beispiel davon ab, wieviel Adressraum die Geräte wegfressen.

volkard schrieb:

Nexx schrieb:

(keine Speicherlöcher, eher falsche Algorithmen [Reservieren <-> Aufräumen])

Schade. Speicherlöcher aus Deinem Quellcode zu finden wären einfach mit einem Debug Heap.

Klingt es realistisch, daß 2.6G benötigt werden? Falls ja, kanns auch daran liegen, daß nach einiger Zeit einfach nicht mehr sagen wie mal 200k *am Stück* frei sind und jemand 200k allokieren will. Und 2.6G sind schon recht viel für ein 32-bittiges Windows. Nicht alle würden das überhaupt einer Anwendung geben können, hängt zum Beispiel davon ab, wieviel Adressraum die Geräte wegfressen.

Hab etwas mehr dazu erfahren:

Details
Falls sich jemand mit VMMap auskennt:
Heap -->
SIZE : 3.731.792K
COMMITED : 2.559.152K
PRIVATE : 2.559.152K
TOTAL WS : 2.481.696K
PRIVATE WS : 2.481.696K
FREE : 115.788K

Ja ist jetzt klar, warum er nicht reservieren kann.
Aber ist das normal, dass SIZE > COMMITED?

p.s. zu dem Zeitpunkt wird bei Prozess Explorer: 2,6GB angezeigt (sprich commited)

greece

hustbaer

Usermode-Adressraum eines normalen 32-Bit Windows Prozesses ist 2GB.

3GB mit dem 3G-Switch und entsprechendem PE-Header Flag.

Knapp 4GB wenn der Prozess auf nem 64 bittigen Windows läuft und die entsprechenden PE-Header Flags hat.

Und klar kann Schluss sein bevor das theoretische Limit erreicht ist. Weil das halt theoretisch ist. Der Speicher fragmentiert ja auch, da ist recht schnell der Punkt erreicht dass man grössere Blöcke nicht mehr unterbringt.

Und ja, "size" > committed ist ganz normal. Gibt ja auch noch "reserved" (=nicht committed, aber Adressraum reserviert).

Kurz: dir geht einfach der Speicher aus.

hustbaer schrieb:

3GB mit dem 3G-Switch und entsprechendem PE-Header Flag.
Knapp 4GB wenn der Prozess auf nem 64 bittigen Windows läuft und die entsprechenden PE-Header Flags hat.

Das hast du richtig getroffen das ist nämlich auch der Fall.

hustbaer schrieb:

Und klar kann Schluss sein bevor das theoretische Limit erreicht ist. Weil das halt theoretisch ist. Der Speicher fragmentiert ja auch, da ist recht schnell der Punkt erreicht dass man grössere Blöcke nicht mehr unterbringt.

Und ja, "size" > committed ist ganz normal. Gibt ja auch noch "reserved" (=nicht committed, aber Adressraum reserviert).

Kurz: dir geht einfach der Speicher aus.

Okey vielen Dank schonmal!
Aber soviel GB virtual Memory ist ja irgendwie nicht normal.

Da sollte ich nochmal gründlichst auf Speicherlöcher untersuchen...