2011-12-18 7 views
5

sguardo qualcosa di strano sul mio Mac:Basta un loop, e 33 perdite

$> 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 

Ed ecco il risultato:

==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) 

Se qualcuno sa perché, e potrebbe spiegami da dove vengono queste perdite, sarei grato !!

Buona giornata :-)

+0

Rieseguire con '--leak-check = full'. Probabilmente vedrai che le allocazioni sono cose di sistema fatte dal tuo ambiente (cose di avvio/inizializzazione una tantum) che non sono realmente fughe di notizie. – Mat

+1

Hai "Riesegui con --leak-check = pieno per vedere i dettagli della memoria trapelata" come suggerito dal messaggio di output di valgrind? – bobbymcr

risposta

9

Queste non sono perdite. Gli oggetti elencati come still reachable non dovrebbero disturbarti. Se avessi un valore diverso da zero nelle righe sopra, allora dovrebbe suonare un campanello d'allarme!

Questi 33 blocchi elencati come still reachable sono probabilmente alcuni blocchi allocati all'interno delle chiamate printf dalla libreria standard. Niente di cui preoccuparsi.

Considerare anche dare un'occhiata a this answer a una domanda simile.

+0

Perfetto. Grazie per la risposta :-) – DCMaxxx

3

"still reachable" quando un programma è terminato è davvero nulla di cui preoccuparsi.

"still reachable" significa che è stata allocata memoria che non è stata rilasciata, ma ci sono ancora puntatori rivolti verso questa memoria. Perciò valgrind non lo segnala come una "perdita" di memoria vera.

Spesso è uno spreco di tempo da dedicare al tempo libero: la memoria allocata prima della fine dell'applicazione, la memoria allocata verrà comunque restituita al sistema operativo poiché l'applicazione sta terminando.

+0

Nella mia esperienza, è importante provare a liberare correttamente tutti gli oggetti alla fine della corsa. Ho trovato un sacco di bug in questo modo. È vero che la gravità della presunta "perdita" è minima, ma l'esercizio nella correttezza che impone ha ampie ripercussioni. Su grandi progetti può fare davvero la differenza. Ha funzionato sui 2 grandi progetti (500K e 150K linee di C) su cui ho lavorato. –

Problemi correlati