Page Faults und Speicherverlust?

[thenoname]

Hallo,

ich habe in einem MFC Program definitv ein Speicherleck.
Der Sysinternals Process Explorer zählt während dem Betrieb ca. 50 - 80 Page Faults pro Sekunde und zeigt immer mehr Speicher im virtuellen Memory unter "Private Bytes" an. Es handelt sich um einen Verlust von in etwa 3kByte/Sekunde.

Nun meine Fragen:
- Was sind "private Bytes"?
- Was sind Page Faults? Muss man diese zuerst angehen? Wie?
- Wie stellt man den Debugger derart scharf, das man dies angezeigt bekommt?

Grüße
TheNoName

[hustbaer]

- Was sind "private Bytes"?

private bytes sind der teil des speichers eines prozesses der

a) belegt ist und
b) nicht mit anderen prozessen geteilt wird

mit anderen prozessen geteilt wird z.b. der platz der für gemeinsam genutzte DLLs verwendet wird, der ganze vom kernel verwendete speicherbereich etc.

und nicht geteilt wird z.b. alles was mit "new"/"malloc" angefordert wird.

- Was sind Page Faults? Muss man diese zuerst angehen? Wie?

vergiss die einfach. in vielen fällen bedeutet eine hohe zahl dort, dass du zu wenig RAM für die workload hast die du deinem PC zumutest. in vielen fällen aber auch nicht, und genau da fängt das problem an.

- Wie stellt man den Debugger derart scharf, das man dies angezeigt bekommt?

garnicht.
"böse" page faults knallt dir der debugger sowieso sofort vor den latz. und ohne debugger beendet das betriebssystem dir das programm, mit den hinweis dass dein programm was gemacht hat, was es nicht machen hätte sollen.

und um "nicht böse" page faults solltest du dich nicht kümmern. "nicht böse" page faults verwendet das betriebssystem z.b. um virtuellen speicher zu realisieren, und noch für etliche andere dinge.

[thenoname]

Danke für die Antwort.

Das mit den Page Faults werde ich mal so hinnehmen.
Interesanterweise kann ich ein leeres MFC "Hallo Welt" erzeugen und wenn ich dieses laufen lasse, dann brauche ich es nur zu berühren und es entstehen Page Faults. Zudem geht auf Dauer ganz gering privater Speicher verloren. Nun gibt es für mich hierzu zwei Erklärungen:

1. ist halt so mit Speicherverlust
2. ein anderes Tool, das einen Hook auf mein Programm erzeugt macht diesen Mist.

Bei 2.) würde ich auf Virenscanner oder Tool neben minimieren Button schätzen (Hardcopy oder Ultramon etc.).

Allerdings hat nun das besagte Program aus dem VorThread einen höheren privaten Verbrauch. Dann müsste ich nach allen new und mallocs suchen. Gibt es hier nicht irgendwelche Heap Tools oder Anzeigehilfen, das man Schritt für Schritt durchsteppt und sieht wann wo Speicher weg sein sollte?
Schön wäre z.B. ein Tool das den privaten Verbrauch pro Thread anzeigt.

[Martin Richter]

1. Eine Debug Version der CRT und MFC wirft Dir Speicherleaks aus, wenn das Programm terminiert und Speicher nicht freigegeben wurde.
2. Was für ein "Hello world" MFC Programm. Selbst da kann man GDI Leaks einbauen...
3. Müsstest Du detailiert sagen welcher Speicherverbrauch Deines Prozesses steigt!
4. Siehst Du im Debugger genau wer sich in Deinen Prozess einhooked!
5. Gibt es nette Tools wie das von Jochen für solche Fälle:
http://www.codeproject.com/KB/applications/leakfinder.aspx

[hustbaer]

Richtig mächtiges Tool kenne ich für Windows und MSVC nur eins, und das ist BoundsChecker. Kostet leider mächtig viel $$$.

[thenoname]

Also ich habe manuel alle mallocs und new überprüft und bin mir keiner Schuld bewusst.
Aber ich glaube das ist bei Programmierern so üblich bis das Gegenteil aufkommt
Das Tool habe ich eingebunden und es werden viele Leaks angezeigt.
Merkwürdigerweise sowas wie "AfxSocketInit()" und viele Teile von mmsystem, also den Multimedia Klassen.
Dazu hab ich dann keinen Einfluss mehr ...

ps. das mit den Hooks ist mir nur aufgefallen, da einige DLL's in meinem Programm geladen sind, die da nicht geladen werden. (Angesehen mit dem Process Explorer)

[volkard]

thenoname schrieb:

Also ich habe manuel alle mallocs und new überprüft und bin mir keiner Schuld bewusst.
Aber ich glaube das ist bei Programmierern so üblich bis das Gegenteil aufkommt

Nein. Speicherlöcher gewöhnt man sich irgendwann ab. Ich benutze beim täglichen Programmieren nichtmal mehr den Debugger. Die logischen Fehler erkenne ich an den falschen Ausgaben und weiß meistens auf Anhieb, welche Zeile ihn verursacht hat und repariere sie gleich. Gegen Optimierungsfehler auf Funktionslevel habe ich die Sicherheitsfunktion, die ich als erstes erstelle, auskommentiert im Code lagern. Manchmal dauert's länger. Aber Speicherlöcher, nichtmal einmal im Jahr.