Durante muchos años un error que aparecía pocas veces pero que trae bastante cola aparece de forma misteriosa y por más que buscamos a qué se debe, no hay forma de eliminarlo. Este mensaje además aparece cuando el sistema tiene un número considerablemente alto de llamadas lo que provoca que se rechacen paquetes UDP que, viniendo de un sistema Asterisk, tiene bastantes posibilidades que sean SIP o UDP, así que lo notaremos tanto por que hay llamadas que no finalizan y el error de FRACK! aparece con bastante frecuencia, entonces también afecta al audio provocando cortes bastante importantes y un gran dolor de cabeza.
Este error se produce en Asterisk y generalmente indica un problema con la integridad de la memoria en tiempo de ejecución. La frase «bad magic number» se refiere a un valor esperado en la memoria que no coincide con el valor real, lo que sugiere que algo ha cambiado la memoria de manera inesperada. En cambio, el mensaje «FRACK!» es una convención de código en Asterisk para indicar un fallo en tiempo de ejecución.
Por más que buscamos en los foros y documentación el origen de este error, parece que se trata de algún problema con alguna versión de Asterisk que parece que se soluciona actualizando la versión de Asterisk, pero llega un momento que actualizas la versión y sigue apareciendo, y como únicamente aparece cuando hay bastante carga, es difícil de detectar y de comprobar si funciona o no la solución.
El error que aparece en el /var/log/asterisk/messages es como este:
[Jan 25 09:01:51] ERROR[8601] modulo.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f4e9f11c440 (0)
[Jan 25 09:01:51] ERROR[8601] : Got 13 backtrace records
# 0: /usr/sbin/asterisk() [0x45c977]
# 1: /usr/sbin/asterisk() [0x45ff1b]
# 2: /usr/sbin/asterisk(__ao2_find+0x28) [0x460108]
# 3: /usr/lib/asterisk/modules/modulo.so(ast_session_get_datastore+0x31) [0x7f50accaf491]
# 4: /usr/lib/asterisk/modules/modulo.so(+0x1f56) [0x7f50ab65ff56]
# 5: /usr/lib/asterisk/modules/modulo.so(+0x11730) [0x7f50af12c730]
# 6: /usr/sbin/asterisk(ast_taskprocessor_execute+0xce) [0x59b61e]
# 7: /usr/sbin/asterisk() [0x5a2d10]
# 8: /usr/sbin/asterisk(ast_taskprocessor_execute+0xce) [0x59b61e]
# 9: /usr/sbin/asterisk() [0x5a34b0]
#10: /usr/sbin/asterisk() [0x5ab34c]
#11: /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f512530c6ba]
#12: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f51248e641d]
El error aparece tanto en chan_SIP como en PJSIP y con otros módulos, pero es un error tan crítico que provoca cortes y grandes problemas de todo tipo.
Descartando un error hardware
Lo primero que tenemos que hacer para solucionar el error FRACK!, Failed assertion bad magic number, es comprobar que el hardware es correcto. El hecho de utilizar un sistema virtualizado no está exento de algún problema físico con la memoria RAM. Para ello, lo suyo es comprobar mediante un test de memoria (memtest86 o similar) que la memoria RAM está bien.
El error FRACK! se soluciona actualizando
En los foros de todo tipo (y he leído foros hasta en ruso o en japonés) hablan de que se soluciona actualizando, por lo que en un primer momento pensé que que el error FRACK!, Failed assertion bad magic number, era un fallo de esa versión en particular y que actualizando a la versión que decía, también se solucionaría.
Error… el FRACK! no se soluciona actualizando a una versión en particular… toca seguir buscando.
No obstante y como vamos a ver ahora, llega un momento en que actualización tras actualización llega un momento en que se soluciona. pero ¿y eso por qué?
Este error ha aparecido desde tiempos inmemorables y como decía antes, siempre en el peor momento: cuando más llamabas había en un Asterisk. Las soluciones, incluso con acceso directo a Digium para intentar solucionarlo siempre se basaban en el mismo sistema: 1) enviar traza, 2) enviar gdb con el error, 3) actualizar la versión de Asterisk, 4) si no se soluciona: Goto(1).
El error FRACK! se debe a la diferencia de versiones entre el sistema operativo y Asterisk
Hay que entender que cada versión de Asterisk se desarrolla en una fecha y en esa fecha existen librerías con versiones más o menos similares.
Puedes instalar Asterisk 20 en una Debian 7, y no dará fallos, pero Asterisk hace uso de funciones en librerías libc, glibc, libssl, etc. estándar de Linux y esperan respuestas que funcionen, pero cuando hablamos de gestión de memoria, las librerías evolucionan y cambian su forma de trabajar y las nuevas versiones de Asterisk esperan una respuesta compatible que en algún momento deja de serlo y entonces se encuentra que una información que debería estar en una posición de memoria, no se encuentra ahí y de ahí el error.
Normalmente con una versión determinada de la distribución que utilices, le acompañan varias versiones de Asterisk, pero si intentas instalar un Asterisk demasiado nuevo o demasiado antiguo, a la hora de compilarlo fallará y no te permitirá hacerlo hasta que no actualices mínimamente.
Si tienes una versión de Linux muy nueva y utilizas una versión de Asterisk antigua, posiblemente te deje instalarlo, pero entonces ocurren los errores de FRACK!, Failed assertion bad magic number… lo mismo si instalas una versión de Linux antigua y Asterisk muy nueva, aunque en este caso, los errores son diferentes (Segmentation Fault, reinicios del Asterisk sin explicación, etc.) por eso es importante que si instalas una versión de tu distribución favorita y esa versión es muy nueva, tendrás que instalar una versión de Asterisk también bastante nueva o tendrás problemas de FRACK!.
De ahí que el error de FRACK! se solucione actualizando la versión de Asterisk.
Cada versión de Asterisk está pensada para una época determinada
En función de la versión de la distribución de Linux, deberás utilizar una versión de Asterisk de ese momento. Todo tiene su momento y aunque siempre se programa para lograr la máxima compatibilidad con todo, haciendo uso de las librerías más modernas pero también las más antiguas, son tantos los factores que intervienen en una aplicación de software, que no queda otra que actualizarse o morir.
Durante muchos años he encontrado de todo, desde versiones de CentOS 5 con Asterisk 1.4 hasta Debian 11 con Debian 1.8., y funcionan… lo que marca la diferencia es cuando realmente pasamos a tener cierto volumen de llamadas y toca hacer un uso intenso de ciertas librerías que manejan software de sistema operativo en capas bajas (reserva de memoria, almacenamiento de datos, procesamiento de números…)
Desde Sinologic siempre hemos defendido que hay que estar constantemente actualizando para evitar fallos de seguridad y recibir las ventajas y mejoras de las actualizaciones que van surgiendo, pero hoy más que nunca, esta recomendación se hace evidente y es que el error FRACK! es para muchos, un gran dolor de cabeza y al menos por mi parte, parece que tiene una solución que, si bien no es fácil, al menos sí es posible y pasa por actualizar Asterisk a una versión «más compatible» con la versión de la distribución de Linux que estemos utilizando.
Entonces la única solución si aparece el error de FRACK! , Failed assertion bad magic number es, o bien reinstalar con una versión de Linux más antigua, o actualizar la versión de Asterisk a una versión compatible con tu distribución, aunque eso implique modificar la configuración para adaptarla a la nueva versión de Asterisk.
Joshua C. Colp es uno de los desarrolladores de siempre que han estado desde siempre en Asterisk y que participa activamente desde hace muchos años, tanto ayudando a los usuarios en el foro y en las listas de correos, como resolviendo bugs y aportando nuevas características a las nuevas versiones de Asterisk.
