Valgrind

Valgrind incluye varias herramientas (además de algunas externas). La herramienta predeterminada (y más utilizada) es Memcheck . Memcheck inserta código de instrumentación adicional alrededor de casi todas las instrucciones, que controla la validez (toda la memoria no asignada comienza como inválida o "indefinida" hasta que se inicializa en un estado determinista, posiblemente desde otra memoria) y la direccionabilidad (si la dirección de memoria en cuestión apunta a un bloque de memoria asignado y no liberado), almacenadas en los llamados bits V y bits A , respectivamente. A medida que se mueven o manipulan los datos, el código de instrumentación realiza un seguimiento de los bits A y V, por lo que siempre son correctos a nivel de bit individual.

Además, Memcheck reemplaza los asignadores de memoria estándar de C++ y el asignador de memoria de C con su propia implementación, que también incluye protecciones de memoria alrededor de todos los bloques asignados (con los bits A configurados como "inválidos"). Esta característica permite a Memcheck detectar errores de desplazamiento de un bit, donde un programa lee o escribe fuera de un bloque asignado por una pequeña cantidad. Los problemas que Memcheck puede detectar y sobre los que puede advertir incluyen los siguientes:

• Lectura de memoria no inicializada
• Lectura/escritura de memoria no válida que puede ser
  • memoria que ha sido free'd
  • memoria fuera de los mallocbloques 'd'
  • memoria por debajo del puntero de pila
• Uso de parámetros incorrectos para las llamadas al sistema
• Copias de memoria superpuestas inseguras mem*con str*funciones
• fugas de memoria
• Asignaciones y reasignaciones desajustes que pueden ser
  • mezclando C y C++ por ejemplo, mallocydelete
  • mezclando escalares y matrices, por ejemplo, newydelete[]
  • El tamaño de la desasignación no es el mismo que el de la asignación.
  • La desasignación alineada no es lo mismo que la alineación que la asignación.
• Uso de alineación incorrecta
• Uso de realloccon un tamaño cero

El precio de esto es la pérdida de rendimiento. Los programas que se ejecutan con Memcheck suelen ser entre 20 y 30 veces más lentos ^{[ 9 ]} que los que se ejecutan fuera de Valgrind y consumen más memoria (hay una penalización de memoria por cada asignación). Por lo tanto, pocos desarrolladores ejecutan su código con Memcheck (o cualquier otra herramienta de Valgrind) de forma continua. Generalmente, utilizan estas herramientas para localizar algún error específico o para verificar que no haya errores latentes (del tipo que Memcheck puede detectar) en el código.

Una parte fundamental de Valgrind siempre debe realizar alguna comprobación en los descriptores de archivo (por ejemplo, para evitar que el ejecutable de prueba afecte al archivo de registro de Valgrind u otros archivos de salida). También se pueden realizar comprobaciones para detectar errores de usuario más generales que afecten a los descriptores de archivo. Los tipos de errores que se detectan son:

• cerrando un descriptor de archivo que no está abierto
• Descriptores de archivo que no se cierran cuando finaliza el ejecutable de prueba.
• uso de un descriptor de archivo que nunca se creó o que ya se cerró

A partir de Valgrind 3.24, estos errores se gestionan de la misma manera que otros errores. Esto significa que se pueden generar y utilizar supresiones con ellos.

Valgrind 3.25 añadió una función que permite modificar el comportamiento de las funciones que crean descriptores de archivo. El comportamiento predeterminado es el mismo que el de POSIX , que devuelve el descriptor de archivo disponible de menor nivel, lo que puede provocar el reciclaje de descriptores de archivo cerrados. Existe el riesgo de que el ejecutable de prueba utilice accidentalmente y de forma errónea un descriptor de archivo reciclado. La opción `--modify-fds` de Valgrind modifica este comportamiento para que ya no respete el estándar POSIX. En su lugar, intentará crear un nuevo descriptor de archivo para cada solicitud.

Además de Memcheck, Valgrind tiene varias otras herramientas: ^{[ 10 ]}

• La opción "Ninguna " ejecuta el código en la máquina virtual sin realizar ningún análisis y, por lo tanto, tiene el menor consumo de CPU y memoria posible de todas las herramientas. Dado que Valgrind proporciona un rastreo de errores en caso de fallo de segmentación , la opción "Ninguna " proporciona este rastreo con un consumo mínimo de recursos.
• Addrcheck , similar a Memcheck pero con un consumo de CPU y memoria mucho menor, detecta menos tipos de errores. Addrcheck se eliminó a partir de la versión 3.2.0. ^{[ 11 ]}
• Massif , un analizador de rendimiento de memoria . La interfaz gráfica independiente massif-visualizer muestra la salida de Massif.
• Helgrind y DRD detectan condiciones de carrera en código multihilo.
• Cachegrind , un analizador de caché . La interfaz gráfica de usuario independiente KCacheGrind visualiza la salida de Cachegrind.
• Callgrind , un analizador de gráficos de llamadas creado por Josef Weidendorfer, se agregó a Valgrind a partir de la versión 3.2.0. KCacheGrind puede visualizar la salida de Callgrind.
• DHAT es una herramienta de análisis dinámico de la memoria que analiza cuánta memoria se asigna y durante cuánto tiempo, así como los patrones de uso de la memoria.
• exp-bbv , un simulador de rendimiento que extrapola el rendimiento a partir de un pequeño conjunto de muestras.

exp-sgcheck (llamado exp-ptrcheck antes de la versión 3.7) se eliminó en la versión 3.16.0. Era una herramienta experimental para detectar errores de desbordamiento de pila y de matriz global, que Memcheck no puede detectar.

También hay varias herramientas desarrolladas externamente disponibles. Una de ellas es ThreadSanitizer, otro detector de condiciones de carrera . ^{[ 12 ] [ 13 ]}