2009-12-06 6 views
1

J'ai donc abandonné l'implémentation de mon propre suivi de fuite de mémoire (dans cette question) et essayer d'utiliser les fonctions MFC pour identifier mes fuites de mémoire. donc je fais exactement ce qui est décrit ici:problème avec MFC Diagnostics

http://msdn.microsoft.com/en-us/library/8ky2wh64(VS.80).aspx

voici mon code:

#ifdef _DEBUG 
    CMemoryState oldMemState, newMemState, diffMemState; 
    oldMemState.Checkpoint(); 
#endif 

    int* test = new int; 

#ifdef _DEBUG 
    newMemState.Checkpoint(); 
    if(diffMemState.Difference(oldMemState, newMemState)) 
    { 
     TRACE("Memory leaked!\n"); 
     diffMemState.DumpStatistics(); 
     diffMemState.DumpAllObjectsSince(); 
    } 
#endif 

mais au lieu de produire toute information utile, la sortie montre

Memory leaked! 
     0 bytes in 0 Free Blocks. 
     4 bytes in 1 Normal Blocks. 
     0 bytes in 0 CRT Blocks. 
     0 bytes in 0 Ignore Blocks. 
     0 bytes in 0 Client Blocks. 
     Largest number used: 0 bytes. 
     Total allocations: 4 bytes. 
     Dumping objects -> 
    {714538} normal block at 0x029628C8, 4 bytes long. 
Data: < > CD CD CD CD 
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp(306) : {714536} client block at 0x022F6040, subtype c0, 68 bytes long. 
    a CWinThread object at $022F6040, 68 bytes long 
    {714535} normal block at 0x03B607A8, 4 bytes long. 
Data: <@`/ > 40 60 2F 02 
    {714534} normal block at 0x03B58C70, 8 bytes long. 
Data: < N  > F0 4E B5 03 00 00 00 00 
    {714533} client block at 0x03B54EF0, subtype c0, 12 bytes long. 
    a CEvent object at $03B54EF0, 12 bytes long 
    {714524} normal block at 0x022FFFC8, 1 bytes long. 
Data: < > CD 
    {714523} normal block at 0x03B608C0, 12 bytes long. 
Data: < x h > E8 07 B6 03 78 08 B6 03 68 97 9A 02 
    {714522} normal block at 0x03B60878, 12 bytes long. 
Data: < 0 P > C0 08 B6 03 30 08 B6 03 50 82 9A 02 
    {714521} normal block at 0x03B60830, 12 bytes long. 
Data: <x   > 78 08 B6 03 E8 07 B6 03 88 81 9A 02 
    {714520} normal block at 0x03B607E8, 12 bytes long. 
Data: <0   > 30 08 B6 03 C0 08 B6 03 CD CD CD CD 
    {714515} normal block at 0x03B606B0, 104 bytes long. 
Data: <    > 00 00 00 00 CD CD CD CD CD CD CD CD CD CD CD CD 
    {714510} normal block at 0x03B60668, 12 bytes long. 
Data: <   > C8 03 B6 03 20 06 B6 03 88 AC 9A 02 
    {714509} normal block at 0x03B60620, 12 bytes long. 
Data: <h  h > 68 06 B6 03 D8 05 B6 03 68 97 9A 02 

.. ....... et cela va et vient et le nombre entre parenthèses est à la baisse (en fait, je n'ai jamais été assez patient pour attendre laissez compter à 1)

il commence toujours à ce nombre élevé 714538 alors - ce que je fais mal?

Merci!

+0

Je crois que nombre est un numéro de ligne. – Synetech

+0

non, selon les docs "Les nombres entre accolades au début de la plupart des lignes spécifient l'ordre dans lequel les objets ont été alloués.L'objet le plus récemment affecté a le nombre le plus élevé et apparaît en haut de la sauvegarde." mais il n'y avait qu'un seul int alloué sur le tas entre les deux checkpoints, donc un tel nombre élevé n'a pas de sens – Mat

Répondre

1

De here il montre que DumpAllObjectsSince() doit être appelée sur l'objet CMemoryState vous avez appelé Checkpoint() sur.

Donc, votre code devrait être:

{ 
      TRACE("Memory leaked!\n"); 
      diffMemState.DumpStatistics(); 
      //diffMemState.DumpAllObjectsSince(); 
      oldMemState.DumpAllObjectsSince(); 
    } 
+0

Hehe c'est tout :) merci beaucoup! – Mat