Valgrint. Visualizando y revisando la memoria.

1 memcheck

gcc -o test.o -g -O0 valgrind_memory_memcheck.c 
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./test.o
Screenshot

Explicación.

Los bloques son localizados en memoria, pero el bloque 2 es el único que es liberado. Los bloques 1 y 3 son bloques que se han perdido y pueden provocar pérdidas de información.

2 Leer/escribir más allá del final de una matriz

Un error común es acceder a los elementos más allá del final de una matriz. A diferencia de java, que generará una excepción cuando lo intentes, en Lenguaje C podría segregarse o podría continuar ejecutándose, produciendo un resultado que es correcto o incorrecto, a veces con resultados que varían entre las ejecuciones. Esto hace que sea difícil localizar este tipo de problema.

gcc -Wall -pedantic -g matrix-leak.c -o matrix.out
valgrind ./matrix.out

Explicación.

Al ejecutar el programa, el programa termina “exitosamente”: no hay ningún error en ejecución. Sin embargo, si hay un error un oculto: acceso a memoria no permitido.

Eso es lo que señala valgrind escritura de un entero (el cual ocupa 4 bytes) en una posición de memoria invalida. La memoria valida son 4 bytes*10 números=40 bytes. Un byte extra es invalido.

3 Leyendo memoria sin utilizar

gcc -Wall -pedantic -g init_variables_leak.c -o leak.out
valgrind ./leak.out

Explicación.

Si bien ii, aa han sido declarados previamente y aa ha sido inicializadas, a[9]a[9] es indefinido. Eso es el error que nos muestra valgrind en la línea 18.

4 Fugas de Memoria

Explicación.

El resumen de Heap es que liberamos solo el último bloque de memoria, mientras que el resto es definivamente pérdido.

Cada vez que llamamos a malloc es creado nuevo espacio de memoria en bytes. En el puntero guardamos la referencia a dicho espacio por lo que si no declaramos un puntero a dicho segmento para ser liberado, habrá problemas de fuga.