2011-12-18 11 views
5

wyglądać dziwnie na moim Mac:Tylko pętla, a 33 przecieków

$> cat main.c 
#include <stdio.h> 
int main(int ac, char **av) { 
    for (int i = 0; i < ac; i++) 
     printf("%s\n", av[i]); 
    return 0; 
} 
$> gcc main.c -std=c99 
$> valgrind ./a.out hello my friends 

A oto wynik:

==725== Memcheck, a memory error detector 
==725== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 
==725== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info 
==725== Command: ./a.out hello my friends 
==725== 
--725-- ./a.out: 
--725-- dSYM directory is missing; consider using --dsymutil=yes 
./a.out 
hello 
my 
friends 
==725== 
==725== HEAP SUMMARY: 
==725==  in use at exit: 6,146 bytes in 33 blocks 
==725== total heap usage: 33 allocs, 0 frees, 6,146 bytes allocated 
==725== 
==725== LEAK SUMMARY: 
==725== definitely lost: 0 bytes in 0 blocks 
==725== indirectly lost: 0 bytes in 0 blocks 
==725==  possibly lost: 0 bytes in 0 blocks 
==725== still reachable: 6,146 bytes in 33 blocks 
==725==   suppressed: 0 bytes in 0 blocks 
==725== Rerun with --leak-check=full to see details of leaked memory 
==725== 
==725== For counts of detected and suppressed errors, rerun with: -v 
==725== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) 

Jeśli ktoś wie dlaczego, a może wyjaśnij mi skąd pochodzą wycieki, byłbym wdzięczny !!

Miłego dnia :-)

+0

Ponownie uruchom z '--leak-check = full'. Prawdopodobnie zobaczysz, że alokacje to rzeczy systemowe wykonane przez twoje środowisko (jednorazowe rzeczy uruchamiania/inicjowania), które tak naprawdę nie są przeciekami. – Mat

+1

Czy "Uruchomiłeś ponownie z --leak-check = full, aby zobaczyć szczegóły wycieku pamięci", jak sugeruje komunikat wyjściowy valgrind? – bobbymcr

Odpowiedz

9

To nie są przecieki. Obiekty wymienione jako still reachable nie powinny Cię niepokoić. Gdybyś miał niezerową wartość w powyższych wierszach, powinien zadzwonić na alarm!

Te 33 bloki wymienione jako still reachable to najprawdopodobniej niektóre bloki przydzielone w ramach wywołań printf przez standardową bibliotekę. Nic się nie martwi.

Warto również rzucić okiem na this answer na podobne pytanie.

+0

Idealny. Dzięki za odpowiedź :-) – DCMaxxx

3

"still reachable" po zakończeniu programu nie ma się czym martwić.

"still reachable" oznacza, że ​​są przydzielone pamięci, które nie zostały zwolnione, ale nadal istnieją wskaźniki wskazujące na tę pamięć. Valgrind nie sygnalizuje tego jako prawdziwego "wycieku" pamięci.

Często tracić czas na poświęcanie wolnego czasu: na przydzieloną pamięć przed zakończeniem aplikacji, przydzielona pamięć zostanie zwrócona do systemu operacyjnego w każdym razie od zakończenia aplikacji.

+0

Z mojego doświadczenia wynika, że ​​próba uwolnienia wszystkich obiektów na końcu biegu jest ważna. W ten sposób znalazłem wiele błędów. To prawda, że ​​grawitacja rzekomego "przecieku" jest minimalna, ale umiejętność poprawnego narzucenia ma szerokie reperkusje. W przypadku dużych projektów może to naprawdę zmienić. Tak naprawdę zrobiłem na dwóch dużych projektach (500K i 150K linii C), nad którymi pracowałem. –