Confusion de la sortie de Valgrind: blocs perdus indirectement mais pas d'erreurs?

Je cours valgrind 3.5.0 pour essayer d'écraser les fuites de mémoire dans mon programme. Je invoque comme si:Confusion de la sortie de Valgrind: blocs perdus indirectement mais pas d'erreurs?

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes

Après mon programme se termine valgrind rapporte que

==22926== 
==22926== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1) 
==22926== malloc/free: in use at exit: 20,862 bytes in 425 blocks. 
==22926== malloc/free: 25,361 allocs, 24,936 frees, 772,998 bytes allocated. 
==22926== For counts of detected errors, rerun with: -v 
==22926== searching for pointers to 425 not-freed blocks. 
==22926== checked 91,884 bytes.

En dépit de me dire qu'il ya des erreurs 0 Je crains que le nombre d'allocations et Libère ne correspondent pas . Plus inquiétant est encore ce qui suit:

==22926== LEAK SUMMARY: 
==22926== definitely lost: 68 bytes in 1 blocks. 
==22926== indirectly lost: 20,794 bytes in 424 blocks. 
==22926==  possibly lost: 0 bytes in 0 blocks. 
==22926== still reachable: 0 bytes in 0 blocks. 
==22926==   suppressed: 0 bytes in 0 blocks.

Il y a sortie supplémentaire, se rapportant à ce qui semble être une fuite:

==22926== 20,862 (68 direct, 20,794 indirect) bytes in 1 blocks are definitely lost in loss record 9 of 17 
==22926== at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224) 
==22926== by 0x807960B: OneTwoThree::OneTwoThree(Scenario const*) (onetwothree.cc:22) 
==22926== by 0x804DD69: main (scsolver.cpp:654)

A la ligne en question dans le constructeur de OneTwoThree je les suivantes :

OneTwoThree::OneTwoThree (const Scenario* scenario) : 
    Choice("123", scenario, new Solution (scenario->name(), scenario)), 
    seen_(new bool [sol_->numVisits()]) 
{ 
}

plus tard, dans le destructor, seen_ est supprimé si:

OneTwoThree::~OneTwoThree() 
{ 
    delete [] seen_; 
}

Il n'y a pas de réaffectation de mémoire associée à seen_; Je retourne seulement les booléens à vrai/faux pendant le cours de mon programme.

Je ne vois pas de fuite ici et je ne comprends pas ce que valgrind essaie de me dire. J'ai lu le manuel valgrind (en particulier, this) mais Je ne suis pas éclairé beaucoup.

Quelqu'un peut-il m'aider à grok cette sortie?

Source

2009-11-04 Daniel

Est-il possible que l'objet 'Solution' * lui-même * ne soit jamais détruit? – Artelius

La classe Choice désaffecte-t-elle le pointeur obtenu dans le constructeur? Il semble que la meilleure conception serait d'avoir la propriété du pointeur dans la même classe - si OneTwoThree alloue de la mémoire, la même instance devrait la désallouer. –

Est-ce que le constructeur Choice et ses proches ont tout libéré? –

Les commentateurs de l'OP étaient sur place; L'objet Solution créé dans le constructeur n'a jamais été supprimé. J'ai corrigé l'oubli flagrant et me suis débarrassé du code laid créant de nouveaux objets en dehors du constructeur de l'objet qui en est responsable.

Merci Artelius, Nikolai et Jonathan!

Source

2009-11-04 03:48:47 Daniel

De plus, des fuites de mémoire peuvent s'infiltrer dans l'opérateur d'affectation lors de la conservation des ressources. Suivez la Loi des Trois Grands: chaque fois que vous écrivez un de Copieur Constructeur, Opérateur d'Affectation ou Destructeur; écrivez les deux autres aussi. Personnellement, je pense que l'opérateur d'affectation est mieux écrit avec l'idiome de copie et d'échange. –

Confusion de la sortie de Valgrind: blocs perdus indirectement mais pas d'erreurs?

Répondre

Questions connexes