Diagnosticar fugas: grafo de memoria, Instruments y pruebas automáticas

Perseguir una fuga leyendo el código es un método pésimo: los ciclos reales rara vez tienen dos nodos, atraviesan capas escritas por gente distinta y a menudo se cierran con una arista que pertenece a un framework. El método que funciona invierte el orden. Primero se produce una evidencia —un objeto que debería estar muerto y no lo está—, después se pregunta al grafo quién lo sostiene, y solo entonces se abre el fichero culpable. Y como el diagnóstico cuesta caro, el trabajo no termina al arreglarlo: termina cuando existe una prueba que vuelve a fallar si alguien reintroduce la retención. Esa prueba, además, es sorprendentemente corta.

El grafo de memoria del depurador

El grafo de memoria de Xcode congela el montículo y lo muestra como lo que es: un grafo dirigido de objetos vivos. Se captura con el botón correspondiente durante una pausa, y para que sirva de algo hay que activar antes el registro de pilas de asignación en las opciones de diagnóstico del esquema; sin él verás qué está vivo pero no de dónde salió. El panel lateral permite filtrar por tipo, y el central muestra, para el objeto seleccionado, las aristas entrantes con el nombre de la propiedad que las produce. Ese detalle es todo el valor de la herramienta: no te dice que hay una fuga, te dice quién retiene a quién y por qué campo.

La técnica que convierte esa foto en un diagnóstico es la repetición. Lleva la aplicación a un estado estable, entra en la pantalla sospechosa, sal, y repite el ciclo tres o cuatro veces antes de capturar. Si al filtrar por el tipo de esa pantalla aparecen cuatro instancias en lugar de una, el número mismo es la prueba y coincide con las veces que entraste. Xcode marca además con un distintivo los bloques que ya reconoce como inalcanzables, pero no te fíes solo de eso: los ciclos que involucran una raíz viva no llevan distintivo y siguen siendo un error.

# Diagnostico desde la terminal, sin Xcode delante
export MallocStackLogging=1        # antes de lanzar el proceso
leaks 4711                         # bloques inalcanzables del proceso 4711
heap 4711 --sortBySize             # censo de instancias por clase
malloc_history 4711 0x600001a2c000 # pila de asignacion de un bloque concreto

Ese censo por clase es especialmente útil cuando la sospecha es difusa: ejecuta el mismo flujo diez veces y compara dos censos. Los tipos cuya cuenta crece linealmente con las repeticiones son los candidatos, y no hace falta ninguna intuición previa sobre dónde está el ciclo.

Fuga no es lo mismo que abandono

El instrumento de fugas hace algo muy concreto y muy limitado: cada cierto tiempo recorre el montículo desde las raíces y señala los bloques que ya no son alcanzables desde ninguna de ellas. Detecta perfectamente los ciclos aislados y los punteros perdidos, y es estructuralmente incapaz de detectar el otro gran patrón de consumo, la memoria abandonada: objetos que siguen siendo alcanzables desde una raíz viva y que nadie va a volver a usar jamás.

Para el segundo caso el instrumento correcto es el de asignaciones con análisis por generaciones. El procedimiento tiene la forma de un experimento controlado: llevas la aplicación a un estado de reposo, marcas una generación, ejecutas la operación completa —entrar y salir, abrir y cerrar, cargar y descartar—, vuelves al mismo estado de reposo y marcas otra generación. Lo que aparezca como persistente en esa generación es memoria que la operación creó y no devolvió. Repítelo tres veces: si el crecimiento persistente es constante en cada vuelta, tienes un problema real; si tiende a cero, era memoria que el sistema cachea con intención.

flowchart TB
s[Sospecha de consumo creciente] --> r[Repetir el flujo varias veces desde un estado estable]
r --> g[Capturar el grafo de memoria]
g --> n[Contar instancias del tipo sospechoso]
n --> m[Hay tantas instancias como repeticiones]
m --> a[Leer las aristas entrantes y nombrar el campo culpable]
a --> f[Degradar esa arista a debil o no propietaria]
n --> u[Hay una sola instancia pero la memoria sube]
u --> gen[Analisis por generaciones en el instrumento de asignaciones]
gen --> ab[Memoria abandonada: revisar caches y colecciones sin limite]
f --> t[Escribir la prueba que fija el resultado]
ab --> t

El test que falla cuando algo no muere

Toda la técnica anterior es cara y manual, y por eso su resultado debe consolidarse en una prueba. El patrón se apoya en una sola idea: si mantienes una referencia débil a un objeto y su ámbito de construcción ya terminó, esa referencia tiene que valer nulo. Si no lo vale, alguien lo retiene.

final class PresentadorTests: XCTestCase {
    func test_elPresentadorNoQuedaRetenido() {
        weak var referencia: Presentador?

        autoreleasepool {
            let sut = Presentador(servicio: ServicioFalso())
            referencia = sut
            sut.cargar()                 // ejercita el camino sospechoso
        }

        XCTAssertNil(referencia, "El presentador siguio vivo tras su ambito")
    }
}

El charco explícito no es decorativo: sin él, cualquier objeto autoliberado por la interoperabilidad con Objective-C podría seguir vivo en el momento de la comprobación y producir un fallo que no corresponde a ninguna fuga. Ejercitar el camino sospechoso dentro del ámbito tampoco es opcional, porque muchos ciclos solo se cierran cuando el objeto se suscribe, registra un observador o guarda un bloque de finalización.

Escribir eso a mano en cada prueba es repetitivo, así que conviene generalizarlo en una utilidad que se enganche al desmontaje de la prueba y que además señale el punto exacto de construcción cuando falle.

extension XCTestCase {
    func rastrearFugas(_ instancia: AnyObject,
                       fichero: StaticString = #filePath,
                       linea: UInt = #line) {
        addTeardownBlock { [weak instancia] in
            XCTAssertNil(instancia,
                         "Instancia no liberada. Posible ciclo de retencion.",
                         file: fichero, line: linea)
        }
    }
}

// En cada fabrica de sujetos bajo prueba
func hacerSut(fichero: StaticString = #filePath, linea: UInt = #line) -> Presentador {
    let servicio = ServicioFalso()
    let sut = Presentador(servicio: servicio)
    rastrearFugas(servicio, fichero: fichero, linea: linea)
    rastrearFugas(sut, fichero: fichero, linea: linea)
    return sut
}

Los parámetros con valores por defecto de fichero y línea hacen que el fallo aparezca marcado en la línea de la prueba que construyó el objeto, y no dentro de la utilidad: sin eso, veinte pruebas fallidas señalan todas al mismo sitio inútil. Con el marco de pruebas moderno la idea es idéntica y el gesto más directo, comprobando la referencia débil con #expect después de que el ámbito de construcción haya terminado.

@Test func elPresentadorNoQuedaRetenido() async {
    weak var referencia: Presentador?

    do {
        let sut = Presentador(servicio: ServicioFalso())
        referencia = sut
        await sut.cargar()
    }

    #expect(referencia == nil)
}

La virtud de este patrón no es que encuentre fugas nuevas —para eso están el grafo y el análisis por generaciones— sino que fija las ya encontradas. Una fuga corregida sin prueba vuelve, porque la arista que la producía suele ser justo la que alguien añade al implementar la siguiente funcionalidad: una referencia de vuelta para “poder avisar”, un caché “temporal”, un observador registrado sin baja. Con la comprobación en el desmontaje, ese cambio se pone rojo en el momento de escribirlo y no seis meses después en un informe de memoria.