2011-12-28 22 views
16

Opracowałem implementację czysto C list FIFO (kolejek) w plikach fifo.h i fifo.c i napisałem program testowy testfifo.c, który kompiluję do ./bin/testfifo. Struktura węzła jest zdefiniowana w list.h.Co oznaczają tłumione przecieki w Valgrind?

uruchomić mój program poprzez Valgrind na OS X 10.6 jak to

valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./bin/testfifo 

i uzyskać następujące dane wyjściowe

==54688== Memcheck, a memory error detector 
==54688== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 
==54688== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info 
==54688== Command: bin/testfifo 
==54688== 
--54688-- bin/testfifo: 
--54688-- dSYM directory is missing; consider using --dsymutil=yes 
==54688== 
==54688== HEAP SUMMARY: 
==54688==  in use at exit: 88 bytes in 1 blocks 
==54688== total heap usage: 11 allocs, 10 frees, 248 bytes allocated 
==54688== 
==54688== LEAK SUMMARY: 
==54688== definitely lost: 0 bytes in 0 blocks 
==54688== indirectly lost: 0 bytes in 0 blocks 
==54688==  possibly lost: 0 bytes in 0 blocks 
==54688== still reachable: 0 bytes in 0 blocks 
==54688==   suppressed: 88 bytes in 1 blocks 
==54688== 
==54688== For counts of detected and suppressed errors, rerun with: -v 
==54688== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) 

Według podsumowania szczelności, nie ma wycieków, ale nadal jestem zastanawiasz się, co to są "stłumione" przecieki. Poza tym liczba przydziałów i darmowych nie pasuje, a więc nie jestem pewien, czy są przecieki, czy nie.

---- EDIT ----

Running

valgrind --tool=memcheck --leak-check=full --show-reachable=yes -v ./bin/testfifo 

na OS X 10.6 produkuje dość długi i mylące wyjście, ale muszę uruchomić

valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./bin/testfifo 

na maszynie Linux ma to wyjście:

==32688== Memcheck, a memory error detector 
==32688== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. 
==32688== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info 
==32688== Command: bin/testfifo 
==32688== 
==32688== 
==32688== HEAP SUMMARY: 
==32688==  in use at exit: 0 bytes in 0 blocks 
==32688== total heap usage: 10 allocs, 10 frees, 160 bytes allocated 
==32688== 
==32688== All heap blocks were freed -- no leaks are possible 
==32688== 
==32688== For counts of detected and suppressed errors, rerun with: -v 
==32688== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) 

Przydziel i teraz jest już mecz, więc dodatkowy przydział na OS X wydaje się być spowodowany pewną biblioteką systemową, jak sugerowano.

Uruchomiłem to samo polecenie za pomocą opcji -v, aby odsłonić 4 pomijane błędy, ale nie mam żadnych łatwo zrozumiałych nowych informacji.

Odpowiedz

20

Są to wycieki poza kodem, w bibliotekach (prawdopodobnie udostępnionych) lub znanych fałszywych alarmach. Bieganie valgrind z numerem -v powinno informować cię o zastosowanych tłumieniach.

+7

Narzędzia do sprawdzania błędów wykrywają liczne problemy w bibliotekach systemowych, takich jak biblioteka C, która jest fabrycznie zainstalowana wraz z systemem operacyjnym. Nie możesz ich łatwo naprawić, ale nie chcesz widzieć tych błędów (i tak, jest ich wiele!), Więc Valgrind odczytuje listę błędów, które należy pominąć przy uruchamianiu. Domyślny plik pomijania jest tworzony przez skrypt ./configure podczas budowania systemu. – Sjoerd

+2

Niektóre z nich nie są również problemami z bibliotekami, ale bibliotekami, które dzielą pamięć między procesami potencjalnie zewnętrznymi dla twojej aplikacji. –

+0

@MichaelMior Yup, Widziałem fałszywe pozytywy z memcheck. – cnicutar