Speicherverbrauch aus core dump lesen
-
Hallo zusammen,
ich habe einen dump, der beim crash mit MiniDumpWriteDump(...MiniDumpWithFullMemory...) automatisch geschrieben wurde. (SetUnhandledExceptionFilter war gesetzt.) Nun interessiere ich mich dafür, wo im Todesmoment wieviel vom Speicher gehalten wurde. Kennt ihr eine Möglichkeit dafür, ohne sich durch alle Objekte, Container usw. in allen Threads (momentan benutze ich Visual C++ 2010 express zum Debuggen) durchzuklicken? Eine Darstellungsart wie bei windirstat, für die irgendwelche Zeiger automatisch aufgelöst werden, fände ich toll.
Gruß
Dobi
-
Wenn Du einen Full Dump hast, dann weisst Du doch wie viel Speicher die Anwendung benutzt hat
das entspricht ungefährt der Größe Deiner Dump-Datei Und Speicher ist Prozess-Lokal und hat nichts mit Threads zu tun...
-
Ja, wieviel es ist, seh ich der Datei an, und es ist zu viel.
Deshalb möcht' ich gern wissen, wer da einfach so viel allokiert hat.
-
Das findest Du so nicht raus.
Wenn Du es nachvollziehen kannst, empfehlen ich Dir umdh zu verwenden... dann siehst Du es relativ einfach...
http://support.microsoft.com/kb/268343/deBeachte aber, dass erst beim Diff-Erzeugen der Callstack korrekt angezeigt wird! Also nicht schon in den log-Dateien!
-
Jochen Kalmbach schrieb:
Das findest Du so nicht raus.
Gemeine Sache. Und wenn ich gar nicht wissen will, an welche Stelle wann allokiert wurde sondern nur gucken will, welche Objekte/Container/sonstwas den Speicher momentan halten (Ich tue mal so als wäre es kein leak, sondern nur greed.), hab ich dann eine Chance? Im Prinzip ist das ja nichts anderes als im VS-Debugger alle Objekte aller Threads in meinem Dump durchzuklicken.
-
Du musst schongezielt wissen wo Du hingreifst. Pauschal eine Art Post-Mortem Trace Funktion aller allokierten Speicherstellen gibt es nicht.
Hilfreich kann sein, einfach mal den Speicher in einem Memory Window durchblätterst. Ich habe so auch schon mal auffälligkeiten entdeckt, aber das geht nur, wenn die Datenm auch für "unser Auge" im Dump erkenbar sind (also Texte).
Ansonsten ist es evtl. eher ratsam Memory-Trace-Points (_CrtMemState, _CrtMemCheckpoint) einzubauen. Geht aber nur in der Debug Version.
-
Martin Richter schrieb:
Hilfreich kann sein, einfach mal den Speicher in einem Memory Window durchblätterst.
Ja, genau das meine ich. Nur, dass ich jemanden suche, der für mich durchblättert und mir dann sagt, wo die dicken Brocken liegen. Ist ein mittelkomplexes Programm aus vor meiner Zeit, dass recht viele Threads benutzt, mit dem ich mich hier rumärgere. Da alles selbst durchzublättern wäre ziemlich übel.
Es knallt leider ziemlich selten (und natürlich auch nur beim Kunden). Debug-Version ist schon drauf. Zusammen aus den Loggings meines Scripts, dass den RAM-Verbrauch mitschreibt, und den normalen Logs geht hervor, dass es irgendwann plötzlich für ein paar Sekunden wie wild anfängt Speicher zu reservieren (ca 80MB zusätzlich zu den 50, die es sonst so braucht), in der Zeit nichts sinnvolles, dann ein paar Sekunden normal weitermacht und dann scheppert. Habt ihr eine vielleicht andere Idee, wie ich das Problem eingrenzen könnte?
Ansonsten werde ich wohl mal eine Version mit tracing bauen.
-
Ich wurde eine versteckte Option einbauen, die dann Speicher-Deltas erst auf Request erzeugt...
