Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » VC++ / MFC » Speicherleck die Zweite

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
16.01.2004, 17:47 Uhr
~iBOT
Gast


Hi Leute,
Ich habe nun nach langem Suchen eine scheinbar nützliches Tool bekommen, kann es jedoch nicht einbinden. Hat jemand kurz lust und Zeit sich das mal anzuschauen? Dann schicke ich ihm gerne den Suorce vom memory manager!
Wäre echt super!
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
18.01.2004, 13:34 Uhr
Spacelord
Hoffnungsloser Fall


Hi,
also Lust mir die Bedienung irgendwelcher Tools anzueignen um dein Problem zu lösen habe ich (und wahrscheinlich die meisten anderen hier) nicht.
Wenn du mit VC++ arbeitest dürften die Bordmittel allerdings ausreichen um dein Speicherleck zu finden.
Hast du schon versucht mit CMemoryState das Problem einzugrenzen?

Wenn wir mal davon ausgehen dass eine Methode dem Optimalfall entspricht und der Speicher der mit new belegt wurde ,am Ende der Funktion,oder meinetwegen auch in einer umschliessenden Funktion wieder freigegeben wird ist das Prinzip folgendes:
- Du erstellst einen "Schnappschuss" des Heaps bevor der Code durchlaufen wird den du im Verdacht hast!
-du erstellst einen zweiten Schnappschuss hinter dem Code den du in Verdacht hast.

Wenn in dem verdächtigen Code sämtlicher Speicher wieder ordentlich freigegeben wurde müsste der Heap beim zweiten Schnappschuss identisch zum ersten sein!!Das lässt sich prüfen! Desweiteren zeigt dir die Methode DumpAllObjectsSince sämtliche Codestellen an,an denen Speicher belegt wurde.Voraussetzung ist allerdings das new durch das Makro DEBUG_NEW ersetzt wird. Das geschieht am einfachsten mit einem #define new DEBUG_NEW(wobei diese Definition nicht vor einem IMPLEMENT_DYNCREATE bzw. IMPLEMENT_SERIAL erscheinen darf)!
Ein Problem könnte dabei die Library darstellen aber wenn eine Funktion aus der Lib dir nen Zeiger auf irgendwas "Neues" liefert sollte klar sein dass es in deine Zuständigkeit fällt das "Neue" bei Bedarf wieder freizugeben.Wenn die Lib intern Schrott macht solltest du ohnehin davon Abstand nehmen .

Ich hab hier nen kleines Beispiel.Ne ganz einfache Dialoganwendung,in der ich absichtlich in der Methode OnButton1 Speicher verbrate.
Wo du die einzelnen Schnappschüsse setzt musst du natürlich selber wissen,vom Prinzip her kannst du einen ganz am Anfang deines Programms machen und einen am Schluss und das Problem dann weiter einkreisen.Im Regelfall hat man aber zumindest einen Verdacht.


C++:
void CMemoryDlg::OnButton1()
{
#ifdef _DEBUG
    #define new DEBUG_NEW
    CMemoryState oldHeapState,newHeapState,heapDifference;
#endif

    int i;
#ifdef _DEBUG
    oldHeapState.Checkpoint();
#endif

    //zu kontrollierender Code
    for(i=0;i<10;i++)
    {
        //Speicher verblasen
        LPDWORD dwArray;
        dwArray =new DWORD[1024];
    }


#ifdef _DEBUG
    newHeapState.Checkpoint();
    if(heapDifference.Difference(oldHeapState,newHeapState))
    {
        TRACE("Speicherleck!!\n");
        heapDifference.DumpStatistics();
        heapDifference.DumpAllObjectsSince();
    }
#endif
    
}




MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.

Dieser Post wurde am 18.01.2004 um 13:40 Uhr von Spacelord editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ VC++ / MFC ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: