Valgrind y los sanitizers en integración continua

Se repite que los sanitizers hicieron obsoleto a Valgrind. Es falso, y creerlo te deja ciego en varios frentes concretos. Son tecnologías distintas —una recompila tu código, la otra emula la máquina— y esa diferencia arquitectónica determina exactamente qué puede ver cada una. Esta lección cierra el nivel enseñándote a elegir entre ambas con criterio y, sobre todo, a montar la batería automática que hace que nada de todo esto dependa de que alguien se acuerde de ejecutarlo.

Dos filosofías

Los sanitizers son un asunto del compilador: modifican tu código al generarlo, insertando comprobaciones donde hace falta y aprovechando toda la información de tipos, tamaños y marcos de pila que solo existe en esa fase. Por eso ven variables locales, globales y campos, y por eso son rápidos: el chequeo son tres instrucciones junto al acceso.

Valgrind no toca tu compilación. Toma el binario ya construido, lo traduce a una representación intermedia llamada VEX, la instrumenta y la recompila a código nativo, bloque a bloque, mientras se ejecuta sobre una CPU sintética. Memcheck, su herramienta estrella, mantiene por cada byte un bit de direccionabilidad y por cada bit un bit de definición. No sabe nada de tus tipos —esa información se perdió al compilar—, pero a cambio ve absolutamente todo lo que la máquina hace, venga del código que sea.

Cuándo Valgrind sigue ganando

Cinco escenarios donde no hay discusión posible:

• No puedes recompilar. Bibliotecas de terceros sin fuente, paquetes de la distribución, binarios ya desplegados, un plugin cargado dinámicamente. Valgrind los instrumenta igual, incluidos el enlazador dinámico y la propia libc.
• Memoria no inicializada sin reconstruir el mundo. Los bits de definición de Memcheck funcionan sobre todo el proceso, sin exigir que cada dependencia esté instrumentada. Es la respuesta pragmática al requisito imposible de MSan que vimos en la lección anterior.
• Perfilado de montículo. Massif te da la evolución del uso de heap en el tiempo y quién lo pidió; DHAT señala bloques que se reservan y nunca se leen, o que viven microsegundos. Ningún sanitizer hace eso.
• Medición determinista. Callgrind y Cachegrind simulan la jerarquía de caché y cuentan instrucciones exactas. Un contador de instrucciones no tiene ruido: puedes detectar una regresión de rendimiento del uno por ciento en una máquina compartida de CI, algo imposible midiendo tiempo de reloj.
• Cadenas de herramientas antiguas o exóticas. Compiladores sin soporte de sanitizers, arquitecturas donde nunca se portaron.

Y las tres debilidades que debes compensar siempre con ASan: Valgrind no detecta desbordamientos de arrays locales ni de globales, porque solo pone zonas rojas alrededor de bloques del montículo; no detecta el uso de un marco de pila ya abandonado; y al serializar los hilos altera radicalmente el entrelazado, lo que oculta carreras que TSan encontraría de inmediato.

# la invocacion util, no la de la wiki
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes \
         --errors-for-leak-kinds=definite --error-exitcode=1 ./prog

# perfilado de montículo y conteo determinista de instrucciones
valgrind --tool=massif ./prog
valgrind --tool=callgrind --cache-sim=yes ./prog

--error-exitcode=1 es la bandera que convierte a Valgrind en una prueba automática: sin ella termina con éxito aunque haya escupido cien errores, y tu integración continua se queda en verde.

Igual que ASan tiene su API de envenenamiento, Valgrind se deja enseñar tus asignadores propios mediante las peticiones de cliente de valgrind/memcheck.h, que describen los bloques que reparte tu arena:

#include <valgrind/memcheck.h>

VALGRIND_MALLOCLIKE_BLOCK(p, n, 0, 0);   /* esto es un bloque de n bytes */
VALGRIND_MAKE_MEM_UNDEFINED(p, n);       /* con contenido aun sin definir */
VALGRIND_FREELIKE_BLOCK(p, 0);           /* y aqui deja de ser valido */

Compiladas fuera de Valgrind, esas macros se convierten en instrucciones inocuas que no cuestan nada, así que pueden quedarse en el código de producción sin condicionales.

La matriz de comprobación

Ninguna configuración sola cubre todas las clases de error, y varias son mutuamente excluyentes. La respuesta profesional no es elegir: es construir la misma suite de pruebas contra varias configuraciones y ejecutarlas todas.

flowchart LR
A[Commit] --> B[Avisos como errores mas analisis estatico]
B --> C[Build asan mas ubsan]
C --> D[Build tsan]
D --> E[Build limpio bajo valgrind memcheck]
E --> F[Fuzzing corto sobre el build asan]
F --> G[Fusionar]
style B fill:#89b4fa,color:#11111b
style C fill:#a6e3a1,color:#11111b
style D fill:#f9e2af,color:#11111b
style E fill:#cba6f7,color:#11111b
style G fill:#a6e3a1,color:#11111b

Con Meson, los directorios paralelos del nivel 17 hacen que esto sea casi gratis, y add_test_setup permite envolver cada prueba en Valgrind sin tocar ni una línea de los tests:

cat >> meson.build <<'EOF'
add_test_setup('valgrind',
  exe_wrapper: [find_program('valgrind'),
                '--leak-check=full',
                '--track-origins=yes',
                '--error-exitcode=1'],
  timeout_multiplier: 20)
EOF

meson setup build-asan -Db_sanitize=address,undefined -Dbuildtype=debugoptimized
meson setup build-tsan -Db_sanitize=thread          -Dbuildtype=debugoptimized
meson setup build-val                                -Dbuildtype=debug

meson test -C build-asan
meson test -C build-tsan
meson test -C build-val --setup=valgrind

Automatizarla

El guion que ata todo esto es más corto de lo que parece, y lo importante son las variables de entorno: sin ellas, los sanitizers informan y siguen adelante, y tu integración continua no se entera de nada.

#!/usr/bin/env bash
set -euo pipefail

export ASAN_OPTIONS=detect_leaks=1:halt_on_error=1:abort_on_error=1:strict_string_checks=1
export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1
export TSAN_OPTIONS=halt_on_error=1:second_deadlock_stack=1
export LSAN_OPTIONS=suppressions=ci/lsan.supp

# 1. el compilador como primer filtro: es gratis y encuentra muchisimo
gcc -std=c23 -Wall -Wextra -Wpedantic -Werror -fanalyzer -c src/*.c -o /dev/null

# 2. la bateria dinamica
meson test -C build-asan --print-errorlogs
meson test -C build-tsan --print-errorlogs
meson test -C build-val  --setup=valgrind --print-errorlogs

Tres reglas para que esto sobreviva al contacto con un equipo real. Primera: la comprobación tiene que ser bloqueante; un aviso que no impide fusionar se ignora en dos semanas. Segunda: separa lo rápido de lo lento —ASan y UBSan en cada empuje, TSan y Valgrind en la rama principal o de noche—, porque una batería que tarda cuarenta minutos acaba desactivada. Tercera: cuando un fallo aparezca, el arreglo es el código, nunca la supresión.