2011-12-18 10 views
5

Look algo extraño en mi mac:Sólo un bucle, y 33 fugas

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

Y aquí está el resultado:

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

Si alguien sabe por qué, y podría explícame de dónde vienen las filtraciones de tesis, ¡estaría agradecido!

Tenga un buen día :-)

+0

Vuelva a ejecutar con '--leak-check = full'. Probablemente verá que las asignaciones son cosas del sistema hechas por su entorno (cosas únicas de inicio/inicialización) que en realidad no son fugas. – Mat

+1

¿"Relanzó con --leak-check = full para ver los detalles de la memoria filtrada" según lo sugerido por el mensaje de salida valgrind? – bobbymcr

Respuesta

9

Estas no son fugas. Los objetos enumerados como still reachable no deberían molestarlo. Si tuviera un valor distinto de cero en las filas de arriba, ¡debería sonar una campana de alarma!

Esos 33 bloques enumerados como still reachable son muy probablemente algunos bloques asignados dentro de las llamadas printf de su biblioteca estándar. Nada de qué preocuparse.

También considere echar un vistazo a this answer a una pregunta similar.

+0

Perfecto. Gracias por la respuesta :-) – DCMaxxx

3

"still reachable" cuando un programa ha finalizado realmente no hay nada de qué preocuparse.

"still reachable" significa que hay memoria asignada que no se ha liberado, pero todavía hay punteros apuntando hacia esta memoria. Por lo tanto valgrind no lo señala como una verdadera "fuga" de memoria.

A menudo es una pérdida de tiempo pasar tiempo libre: al ingresar la memoria asignada antes de que finalice una aplicación, la memoria asignada se devolverá al sistema operativo de todos modos ya que la aplicación está finalizando.

+0

En mi experiencia, es importante tratar de liberar todos los objetos correctamente al final de su carrera. He encontrado muchos errores de esa manera. Es cierto que la gravedad de la supuesta 'fuga' es mínima, pero el ejercicio en exactitud que impone tiene amplias repercusiones. En grandes proyectos, puede marcar una gran diferencia. De hecho, lo hizo en los 2 grandes proyectos (500K y 150K líneas de C) en los que trabajé. –

Cuestiones relacionadas