Guard Malloc encontró el error EXC_BAD_ACCESS al instante. ¿Por qué no usar todo el tiempo?

Question

He estado depurando el infame error EXC_BAD_ACCESS durante unos días. NSZombieEnabled = SÍ no ofreció nada. La pila de llamadas era diferente cada vez que recibía el error, que era una vez cada 5 o 6 ejecuciones.

Vi un consejo para habilitar guard malloc (que se encuentra en el editor de esquemas ahora para Xcode 4) en el sitio web de Lou Franco: Understanding EXC_BAD_ACCESS. Tan pronto como hice esto, mi programa se detuvo en la línea exacta que causaba este elusivo error.

De acuerdo con su descripción, guard malloc crea páginas separadas para cada malloc y borra toda la página cuando se libera la memoria, bloqueando así el programa cuando se accede a la memoria liberada. Para el desarrollo general, ¿por qué no debería mantener el guardia malloc todo el tiempo? Parece detectar ciertos tipos de errores de memoria fácilmente. Si no estoy probando la gestión de la memoria o el rendimiento específicamente, ¿hay alguna desventaja de su uso?

Answer 1

No solo desperdicia espacio de direcciones, sino que ralentiza significativamente su programa (potencialmente hasta el punto en que no se puede usar, incluso en el simulador). Supongo que para un programa de iOS cuando lo ejecuta en el simulador es un poco discutible (la memoria no es un problema, y ​​el rendimiento no es terrible tampoco), pero quizás en nombre de las mejores prácticas no debería ejecutarlo constantemente.

Answer 2

Asignando una página entera de 4K para un par de bytes por malloc() espacio de direcciones de desechos muy rápidamente.

Answer 3

GuardMalloc hace que la aplicación se ejecute mucho más lentamente, especialmente si tiene un gran número de asignaciones durante el curso normal de ejecución. Lo mantengo apagado la mayor parte del tiempo.

Activo GuardMalloc para solucionar un fallo que destruye la pila. A menudo, estos tienen objc_msgSend en la parte superior de lo que queda de la pila.

Con GuardMalloc, se evitan los efectos aleatorios de los punteros colgantes. La dirección en el puntero no se puede reutilizar y su ubicación de memoria se invalida. El bloqueo ocurrirá casi de inmediato, mucho antes de que la pila esté corrupta. Esto es genial para el código heredado C++ así como para el nuevo Objective-C.

Dejo las otras ayudas de depuración de memoria a tiempo completo.