Speicherlecks, die von CRT Memory Leak Detection nicht erkannt werden

Question

Ich habe das Problem, dass meine Anwendung ein unendlich wachsendes Memory Leak hat, das nicht erkannt wird. Was ich sehr vereinfacht tue, ist, ein Objekt zu erstellen, eine Methode darauf auszuführen und dann das Objekt zu löschen. Jedes Mal, wenn ich dies tue, wächst der Speicherverbrauch im TaskManager um etwa 50-100MB. Dies erschöpft nach einigen Durchläufen meinen gesamten Speicher. Ich mache das mit Multithreading, aber es gibt keine statischen Variablen, so dass es keine Kollisionen zwischen den verschiedenen Objekten in meinen Threads gibt. Sie verwenden nur statische Methoden anderer Objekte, die keinen anderen Speicher als den in den Parametern übergebenen verändern - es ist also thread-sicher. Ich habe versucht, den Grund dafür herauszufinden:

• Ich verwende crtdbg.h (CRT-Memeory-Leak-Detection), aber es gibt nur Lecks, die seit dem Start meiner Anwendung existieren - sie werden beim Herunterfahren gelöscht und sind nicht so groß.
• Ich habe nach den virtuellen Destruktoren in allen Objekten gesucht, von denen ich erbe, aber sie sind alle OK

Was kann ich noch versuchen, um herauszufinden, wo meine Bewerbung undicht ist? Ich kann keine Lecks im HEAP finden und ich kenne keine anderen Gründe als das Destruktorproblem, das Lecks im STACK verursachen kann (damit meine ich, dass ein Objekt ein lokales std::string-Objekt nicht zerstört, das Platz im Heap zugewiesen hat). Ich weiß nicht, ob es noch andere Gründe für "STACK-Leaks" gibt, aber ich weiß, dass es in den Teilen meiner Methode, in denen der Speicher am meisten wächst, keine HEAP-Allokation gibt.

Answer 1

Wahrscheinlich wollen Sie einen schöneren, robusteren Lecksucher verwenden. Möglicherweise müssen Sie auch einen Leckdetektor verwenden, der einen Heap-Bericht zu verschiedenen Zeiten ausgeben kann, während Ihr Programm läuft. Schließlich sollten Sie in Betracht ziehen, dass Ihr Problem eher auf eine Heap-Fragmentierung als auf ein Leck zurückzuführen sein könnte.

Sie können versuchen Visueller Leckdetektor das kostenlos bei Google erhältlich ist.

Diese Frage enthält eine Liste anderer Produkte zur Überprüfung des Arbeitsspeichers, von einfachen bis hin zu sehr fortgeschrittenen/teuren Produkten. CRTDBG ist die Lösung mit dem kleinsten gemeinsamen Nenner; ich habe gute Erfahrungen mit BoundsChecker gemacht, obwohl es nicht kostenlos ist.

Answer 2

Ich bin mir nicht sicher, wie Sie die CRTDBG-Bibliothek verwendet haben, aber sie bietet eine Menge nützlicher Funktionen:

http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

Sie können _CrtMemCheckpoint nach dem Prinzip "Teile und herrsche" verwenden. Es erlaubt Ihnen, den Unterschied im Speicherverbrauch zwischen zwei Punkten in Ihrem Code zu messen. Bei Multithreading kann dies schwierig sein.

Eine andere ist _CrtDumpMemoryLeaks (die ich nehme an, wird sowieso auf app Ende ausgeführt) mit _CRTDBG_MAP_ALLOC aktiviert, sollte dies genaue Position der Speicherzuweisungen zeigen.

Ein weiterer Hinweis ist, dass Sie vielleicht Ihr CRTDBG überkonfiguriert haben, mit vielen kleinen Zuweisungen kann es riesige interne Speicherstrukturen erzeugen.

Versuchen Sie, Teile Ihres Codes auszuschalten, und prüfen Sie, ob das Problem weiterhin besteht.

Wenn Sie Ihre Anwendung täglich erstellen, versuchen Sie, frühere Versionen auszuführen, um festzustellen, wo das Problem aufgetreten ist, und vergleichen Sie dann die Änderungen im Quellcode-Repository.

...