CursosOnlineEnDirecto-Benowu

Cómo Lidiar con Bugs Intermitentes

Cómo Lidiar con Bugs Intermitentes

El bug intermitente es primo del escorpión espacial invisible de 50 pies. Esta pesadilla ocurre tan raras veces que es difícil de observar, pero lo suficientemente a menudo como para que no pueda ser ignorado. No puedes depurarlo porque no puedes
encontrarlo.

Aunque después de 8 horas empezarás a dudarlo, el bug intermitente tiene que obedecer a las mismas leyes de la lógica que todo lo demás. Lo que lo hace difícil es que ocurre solamente bajo condiciones desconocidas. Trata de registrar las circunstancias bajo las cuales ocurre el bug, de tal manera que puedas adivinar realmente en qué yace la variabilidad. La condición puede estar relacionada a los valores de los datos, tales como 'Esto sólo sucede cuando introducimos Wyoming
como valor.' Si eso no es la fuente de la variabilidad, la próxima sospecha debería ser la concurrencia inapropiadamente sincronizada.

Trata, trata, trata de reproducir el bug de una forma controlada. Si no puedes reproducirlo, configura una trampa para él mediante la construcción de un sistema de registro de sucesos (logging), una especial si tienes que hacerlo, que pueda registrar
lo que supones que necesitas cuando realmente ocurre. Resígnate a ti mismo a que si el bug solamente ocurre en producción y no a tu antojo, este sea quizá un largo pero pueden darte suficiente información para mejorar el registro de sucesos. El
sistema mejorado de registro de sucesos puede requerir un largo tiempo para estar en producción. Luego, tienes que esperar a que reaparezca el bug para obtener más información. Este círculo puede seguir por algún tiempo.

El bug intermitente más estúpido que he creado fue en una implementación multi-hilo de un lenguaje de programación funcional para un proyecto de clase. Me había asegurado cuidadosamente de la correcta evaluación concurrente del programa
funcional y la buena utilización de todas las CPUs disponibles (ocho, en este caso).

Simplemente olvidé sincronizar el recolector de basura. El sistema podría correr un largo tiempo, a menudo finalizando cualquier tarea que comenzara, antes de que algo notable fuese mal. Estoy avergonzado al admitir que había comenzado a cuestionar al hardware antes de que mi error me pusiera en evidencia.

En el trabajo recientemente teníamos un bug intermitente que nos tomó varias semanas encontrar. Tenemos servidores de aplicación multi-hilados en Java™ detrás de servidores web Apache™. Para mantener cambios de página rápidos, hacemos
toda la E/S en pequeños conjuntos de cuatro hilos separados que son diferentes de los hilos cambia páginas. Aparentemente cada cierto tiempo esos hilos se 'clavaban' y cesaban de hacer cualquier cosa útil, hasta que nuestro registro de sucesos nos
permitió determinarlo, por horas. Puesto que teníamos cuatro hilos, esto no era en sí mismo un problema gigante---a menos que los cuatro se clavaran. Luego esas colas vaciadas por esos hilos rápidamente llenarían toda la memoria disponible y hacían
aterrizar nuestro servidor. Nos tomó cerca de una semana entender esto, y aún no sabíamos qué lo causaba, cuándo sucedía, e incluso qué estaban haciendo los hilos cuando se 'clavaban'.

Esto ilustra algunos riesgos asociados con software de terceros. Estábamos usando una pieza de código licenciada que removió las etiquetas HTML del texto. Debido a su lugar de origen nos referíamos a él entrañablemente como 'el stripper francés.'
Aunque teníamos el código fuente (¡bondadosa gracia!) no lo habíamos estudiado cuidadosamente hasta cuando activamos el registro de sucesos en nuestros servidores que finalmente nos dimos cuenta que los hilos del email estaban clavando en el stripper francés.

El stripper se desempeñaba bien excepto en algunos largos e inusuales tipos de textos. En esos textos, el código era cuadrático o peor. Esto significa que el tiempo de procesamiento era proporcional al cuadrado de la longitud del texto. Si esos textos hubieran ocurrido comúnmente, hubiésemos encontrado el bug de inmediato. Si no hubieran ocurrido del todo, nunca hubiésemos tenido un problema. Como suele suceder, nos tomó semanas para finalmente comprender y resolver el problema.

 

Fuente:

Cómo Ser Un Programador: Un Resumen
Corto, Comprensivo y Personal
por Robert L. Read

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Subir

Canal de aprender-libre.com

Reciba todas las publicaciones desde nuestro canal en Telegram

UNIRSE
CERRAR