Depurar lo difícil: crashes raros y sanitizers

Hay una clase de fallos que resiste al método habitual porque rompe su supuesto básico: que puedes volver a provocarlos. Un crash que aparece una vez cada trescientos arranques, una carrera de datos que solo se manifiesta en un dispositivo con seis núcleos bajo carga térmica, una corrupción de memoria que estalla veinte minutos y tres subsistemas después de haberse cometido. Con estos bugs, sentarse a poner puntos de interrupción es perder el tiempo. La técnica que funciona consiste en dejar de perseguir el síntoma y cambiar el programa para que el fallo se vuelva ruidoso, determinista y local: eso es exactamente lo que hacen los sanitizers y las guardas de ejecución, y por eso son la herramienta central de esta lección y no un apéndice.

Cercar lo que no se reproduce

Lo primero es aceptar que un fallo intermitente no es un fallo sin causa, sino un fallo cuya causa depende de variables que no estás controlando: el número de núcleos activos, la latencia de la red, el orden en que despiertan dos colas, si el sistema ya expulsó una página. El trabajo consiste en identificar esas variables y empujarlas, no en repetir la misma prueba con más paciencia.

El informe de fallo es el punto de partida y contiene más de lo que parece. La firma de excepción ya clasifica: un EXC_BAD_ACCESS con dirección baja suele ser una referencia nula, con dirección alta y arbitraria apunta a un puntero colgante o a corrupción; un EXC_BREAKPOINT suele venir de una comprobación del lenguaje, como desenvolver un opcional vacío o un desbordamiento aritmético; una terminación por watchdog no es un crash de código sino un bloqueo del hilo principal. Además, el informe trae todos los hilos, no solo el que falló, y en los bugs de concurrencia la pila del hilo que no falló es casi siempre la que explica el fallo.

Sobre esa base, tres tácticas aumentan la probabilidad del suceso hasta hacerlo observable.

• Estresar la programación: ejecutar en el dispositivo más rápido y en el más lento, provocar contención con trabajo artificial, y repetir la operación sospechosa en bucle desde un test.
• Amplificar la ventana: introducir esperas deliberadas dentro de la región sospechosa. Si un sleep de diez milisegundos entre dos accesos convierte un fallo raro en un fallo constante, acabas de demostrar que hay una ventana de carrera.
• Registrar antes de fallar: un os_signpost en cada frontera de estado deja una traza que sobrevive al crash y que reconstruye el orden real de los eventos.

Thread Sanitizer: qué detecta y qué no

TSan no adivina ni prueba mil ordenaciones. Instrumenta cada acceso a memoria y mantiene, por hilo, un vector de relojes que registra qué eventos de otros hilos ha visto ya. Cuando dos hilos acceden a la misma dirección, al menos uno escribe, y entre ambos accesos no existe una relación de ocurre antes establecida por una primitiva de sincronización reconocida, declara una carrera de datos.

Lo decisivo de ese algoritmo es que no necesita que el fallo se manifieste. Detecta la carrera aunque en esa ejecución concreta el orden haya sido benigno y el resultado correcto, que es precisamente el caso en el noventa y nueve por ciento de las ejecuciones de un bug intermitente. Ahí está su enorme valor: convierte un fenómeno probabilístico en un diagnóstico determinista.

Sus límites son igual de precisos y hay que conocerlos.

• Solo ve el código que se ejecuta. Un camino que tu prueba no recorre no se analiza, así que TSan pide cobertura, no solo activación.
• Solo ve accesos instrumentados. Bibliotecas de terceros compiladas sin él quedan como puntos ciegos.
• Multiplica el tiempo de ejecución por entre cinco y quince y el uso de memoria por varias veces, lo que lo hace inviable en producción y lo confina a pruebas y sesiones dirigidas.
• Es incompatible con otros sanitizers en el mismo esquema, así que hay que decidir qué se busca antes de ejecutar.

// Carrera clasica: TSan la senala aunque el resultado parezca correcto
final class Contador {
    private var valor = 0
    func incrementar() { valor += 1 }      // lectura y escritura sin proteccion
    var actual: Int { valor }
}

// Una de las correcciones idiomaticas: aislar el estado en un actor
actor ContadorSeguro {
    private var valor = 0
    func incrementar() { valor += 1 }
    var actual: Int { valor }
}

flowchart TD
A[Sintoma observado] --> B{Que clase de fallo}
B -- Cuelgue o dato corrupto entre hilos --> C[Thread Sanitizer]
B -- Acceso invalido o direccion rara --> D[Address Sanitizer]
B -- Aritmetica o conversion sospechosa --> E[Undefined Behavior Sanitizer]
B -- Objeto liberado que responde --> F[Zombie Objects]
B -- Interfaz tocada fuera del hilo principal --> G[Main Thread Checker]
C --> H[Corregir la sincronizacion y volver a ejecutar]
D --> H
E --> H
F --> H
G --> H

El resto del arsenal

TSan cubre una sola familia. Las demás tienen su propia herramienta, y elegir la correcta ahorra días.

El Address Sanitizer detecta accesos fuera de límites, uso después de liberar y desbordamientos de pila, colocando zonas envenenadas alrededor de cada asignación y retrasando la reutilización de la memoria liberada. Su virtud es que dispara en el instante del acceso ilegal y no veinte minutos después, que es cuando normalmente estallaría; su coste ronda el doble de tiempo y bastante más memoria.

El Undefined Behavior Sanitizer inserta comprobaciones para desbordamientos de enteros, desplazamientos inválidos, punteros mal alineados y conversiones que pierden información. Es el más barato de todos y el que más veces encuentra bugs latentes en código de interoperación con C.

Las guardas de asignación vienen de las variables de entorno del esquema y siguen siendo insustituibles. Los objetos zombis impiden que una instancia liberada devuelva su memoria y hacen que cualquier mensaje posterior falle con el nombre exacto de la clase, lo que convierte un crash indescifrable en una frase. MallocScribble rellena la memoria liberada con un patrón reconocible, y MallocGuardEdges coloca páginas protegidas en los bordes de las asignaciones grandes.

Y el Main Thread Checker merece estar siempre activo en depuración: casi ningún equipo llega a la fase de sanitizers sin haber pasado antes por un bug causado por tocar la interfaz desde una cola de fondo.

Un protocolo para el fallo que no se deja atrapar

Cuando ninguna herramienta dispara, queda el método, y el método tiene un orden que evita perder semanas.

Uno. Escribir la hipótesis en una frase falsable. No hay un problema de concurrencia, sino dos tareas escriben el mismo diccionario del caché sin sincronización. Solo una frase así indica qué experimento la refutaría.

Dos. Reducir el programa hasta el mínimo que aún falla. Quitar pantallas, desactivar módulos, sustituir la red por respuestas fijas. Cada eliminación que conserva el síntoma acorta el espacio de búsqueda a la mitad, y cada una que lo elimina señala al sospechoso.

Tres. Encerrar el sospechoso en una prueba que se ejecute mil veces. Un bucle de repetición con concurrencia real convierte un suceso de una vez cada trescientos arranques en un fallo de cada ejecución.

@Test func elCacheAguantaAccesoConcurrente() async {
    let cache = Cache()
    await withTaskGroup(of: Void.self) { grupo in
        for i in 0..<1_000 {
            grupo.addTask { await cache.guardar(valor: i, en: "clave\(i % 8)") }
        }
    }
    #expect(await cache.recuento == 8)
}

Cuatro. Ejecutar esa prueba bajo el sanitizer que corresponda a la hipótesis, no bajo todos por turnos. La elección del instrumento es la prueba de la hipótesis; probar al azar produce ruido y consume la paciencia del equipo.

Cinco. Comprobar que la corrección elimina la causa y no el síntoma. La señal de alarma es haber arreglado el fallo cambiando algo que, por su naturaleza, no podía influir en la propiedad violada: mover una línea, añadir un registro, reordenar dos asignaciones independientes. Si la explicación de por qué funciona ahora no cabe en una frase, lo más probable es que el bug siga ahí esperando a otro compilador.

Seis. Cuando se corrija, dejar la prueba en la suite. Un fallo intermitente que vuelve seis meses después sin test es un fallo nuevo con todo el coste de investigación otra vez, y además llega ya con la confianza del equipo gastada.