English

Ejecuta tu suite de pruebas nativas bajo sanitizers

En C y C++, perseguir la cobertura de líneas pasa por alto los bugs que de verdad te hacen crashear. Ejecuta tu suite bajo sanitizers. La cobertura de líneas te dice que una línea se ejecutó — no te dice nada del use-after-free, del overflow con signo ni del data race escondido en esa misma línea. Los sanitizers instrumentan el runtime, así que las mismas pruebas que ya tienes empiezan a fallar en los bugs que importan.

Por qué la cobertura de líneas engaña al código nativo

Un reporte de cobertura responde una sola pregunta: ¿se ejecutó esta línea? En lenguajes gestionados es un proxy razonable de "este comportamiento se verificó". En C y C++ no lo es, porque los peores modos de falla son silenciosos en tiempo de ejecución: una lectura fuera de límites devuelve basura que parece válida, un use-after-free lee memoria obsoleta pero plausible, el comportamiento indefinido se optimiza en algo que solo falla con -O2, y un data race pasa 999 de cada 1,000 corridas. Todas esas líneas aparecen verdes en el reporte de cobertura. El bug se lanza igual.

Los tres sanitizers y qué te da cada uno

Cada sanitizer es un flag de compilación y enlazado más un runtime instrumentado. Las mismas pruebas, sin aserciones nuevas.

Empezar es una sola recompilación de tus binarios de prueba:

# ASan + UBSan combine in a single build:
clang++ -fsanitize=address,undefined -fno-sanitize-recover=all \
        -g -O1 -fno-omit-frame-pointer tests.cc -o tests_asan
./tests_asan

# TSan is a separate build — it can't share a binary with ASan:
clang++ -fsanitize=thread -g -O1 tests.cc -o tests_tsan
./tests_tsan

Tres detalles que importan: enlaza con el driver del compilador (clang++), no con ld, para que los runtimes de los sanitizers se incluyan; agrega -g -fno-omit-frame-pointer para que los reportes tengan stack traces útiles; y pasa -fno-sanitize-recover=all para que UBSan termine en el primer hallazgo en vez de imprimir y continuar — en CI, una advertencia que nadie lee es un bug que nadie arregla.

Lo que esto atrapa y la cobertura jamás verá

Las corridas con sanitizers sacan a la luz use-after-free, lecturas fuera de límites, overflows con signo y races que un tablero de cobertura totalmente verde lanzaría a producción sin problema. Y los hallazgos se acumulan: cada reporte de sanitizer trae un stack trace que apunta a un defecto reproducible. Convierte cada uno en una prueba de regresión permanente, y tu suite se fortalece con cada captura. Para código nativo, una suite que corre limpia bajo ASan, UBSan y TSan suele ser una señal más fuerte que otros cinco puntos de cobertura de líneas.

Trucos avanzados

• Corre los jobs de sanitizers en CI como entradas separadas de la matriz. Un job ASan+UBSan y un job TSan. Con ~2x de ralentización, ASan es lo bastante barato para cada pull request; TSan puede correr en nightly si tu suite es larga.
• Ajusta el comportamiento en runtime con variables de entorno — ASAN_OPTIONS, UBSAN_OPTIONS, TSAN_OPTIONS — p. ej. ASAN_OPTIONS=halt_on_error=1 o UBSAN_OPTIONS=print_stacktrace=1. Sin recompilar.
• Suprime el ruido de terceros, no tus propios bugs. Los tres sanitizers soportan archivos de supresión para reportes en código que no es tuyo. Mantén el archivo en el repo y bajo revisión — una lista de supresiones sin revisar se convierte en silencio en una lista de ignorar todo.
• Ambos compiladores principales entienden estos flags. GCC y Clang soportan -fsanitize=address, -fsanitize=undefined y -fsanitize=thread, así que esto funciona con cualquiera que sea tu toolchain.
• Apunta a tu agente de AI coding a la salida del sanitizer. Un stack trace de sanitizer es exactamente la señal de falla precisa y reproducible que le permite a un agente arreglar el bug real en vez de adivinar.

Recursos

• AddressSanitizer — documentación de Clang
• UndefinedBehaviorSanitizer — documentación de Clang
• ThreadSanitizer — documentación de Clang
• Wiki de AddressSanitizer — google/sanitizers
• Program Instrumentation Options (-fsanitize=) — manual de GCC