2012-11-14 15 views
5

Ich habe ein sehr seltsames Problem mit Speicherlecks. Ich benutze _CrtDumpMemoryLeaks um Lecks zu überprüfen. Hier ist meine WinMain Funktion:Seltsame "Memory Leak Detection" Fehler C++

int APIENTRY _tWinMain(_In_ HINSTANCE hInstance, 
        _In_opt_ HINSTANCE hPrevInstance, 
        _In_ LPTSTR lpCmdLine, 
        _In_ int  nCmdShow) 
{ 
    UNREFERENCED_PARAMETER(hPrevInstance); 
    UNREFERENCED_PARAMETER(lpCmdLine); 

    ////////////////// SET UP CHECKS FOR MEMORY LEAKS //////////////////// 
    _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); 
    ////////////////////////////////////////////////////////////////////// 


    _CrtDumpMemoryLeaks(); // Reports leaks to stderr 

    return 0; 
} 

Wie Sie sehen können, habe ich entfernt haben komplett alles von ihm nur zu prüfen, ob ich vielleicht eine Art von Fehlalarmen zu bekommen.

Nachdem ich eine Anwendung zu schließen, erhalte ich diese Gruppe von Speicherlecks in der Ausgabe:

Detected memory leaks! 
Dumping objects -> 
{1343} normal block at 0x06076780, 8 bytes long. 
Data: < g  > 20 67 07 06 00 00 00 00 
{1342} normal block at 0x06076710, 52 bytes long. 
Data: <@ @ @  > 40 16 07 06 40 16 07 06 40 16 07 06 01 00 CD CD 
{1341} normal block at 0x060766B0, 32 bytes long. 
Data: <C:/Windows/Fonts> 43 3A 2F 57 69 6E 64 6F 77 73 2F 46 6F 6E 74 73 
{1339} normal block at 0x0607F438, 16 bytes long. 
Data: <    P > C0 17 0B 01 01 00 00 00 01 00 00 00 80 13 50 04 
{1338} normal block at 0x04501380, 8 bytes long. 
Data: < H > BC 0D 0B 01 48 18 07 06 
{1295} normal block at 0x060716B0, 8 bytes long. 
Data: <  > B4 B3 0B 01 00 00 00 00 
{1294} normal block at 0x06071640, 52 bytes long. 
Data: < g g g  > 10 67 07 06 10 67 07 06 10 67 07 06 01 01 CD CD 
{1293} normal block at 0x0450DFB8, 8 bytes long. 
Data: < ! P > E0 21 0B 01 98 05 50 04 
{1292} normal block at 0x0450E110, 8 bytes long. 
Data: < P  > E8 05 50 04 00 00 00 00 
// (There's like thousand more of those...) 
Object dump complete. 

Ich habe völlig keine Ahnung, wo sie herkommen kann.

Vielen Dank im Voraus für jede Antwort.

Antwort

4

Überprüfen Sie das Ausgabefenster. Sehen Sie eine Reihe von DLLs geladen werden? Jeder von ihnen kann Datenstrukturen statisch initialisieren, die nicht freigegeben werden, bevor Sie die Leckausgabe aufrufen. Probieren Sie den Tipp here aus, um einen Teil dieses Rauschens auszuschließen, indem Sie Ihre Leckprüfung auf einen bestimmten Bereich der Ausführungszeit beschränken.

Da der statisch initialisierte Singleton von Google Test Zuordnungen auf dem Heap erfordert, meldet der Visual C++ - Speicherleckdetektor am Ende des Programmlaufs Speicherlecks. Der einfachste Weg, dies zu vermeiden, ist die Verwendung der Aufrufe _CrtMemCheckpoint und _CrtMemDumpAllObjectsSince, um keine statisch initialisierten Heap-Objekte zu melden. Weitere Informationen und zusätzliche Heap-Check/Debug-Routinen finden Sie unter MSDN.

+0

Danke für die Antwort, Steve! :-) –

+0

Gern geschehen, ich wusste nicht, dass du ein Zeitfenster so einfangen kannst, bis ich über dein q nachdenken musste –