[Sábado 2 de marzo de 1996, 10:32:33 PST CÓMO-Rastrear un fallo en el núcleo lm@sgi.com (Larry McVoy)] A continuación, veremos cómo seguir el rastro de un fallo del núcleo, suponiendo que no se poseen conocimientos del nivel de un hacker del núcleo. Este método es tan sólo una aproximación mediante el empleo de la fuerza bruta, aún así funciona bastante bien. Requisitos: . Un error reproducible. Esto es que debe ocurrir de una manera predecible (lo siento). . Todos los archivos tar del núcleo de una versión que funciona correctamente (que no tiene el fallo) así como los de una que no. Procedimiento: . Recompilar la versión que, supuestamente, funciona correctamente, instalarla y comprobar que en realidad no tiene el fallo. . Realizar una búsqueda binaria entre los núcleos para averiguar en cuál se introdujo el fallo. Es decir, supongamos que el núcleo 1.3.28 no tenía el fallo pero sabemos que el 1.3.69 lo tiene, entonces seleccionamos una versión intermedia, por ejemplo la 1.3.50 (28 + 69 = 99; 99 / 2 ~= 50). Compilamos y probamos: si funciona escogemos la versión que está en medio de la .50 y la .69; en caso contrario, tomamos la intermedia entre la .28 y la .50. . De esta manera conseguimos localizar la versión en la que se introdujo el fallo. No obstante, es posible hacerlo de una forma más rápida, aunque se complicaría el método. . Reduciendo la localización a un subdirectorio: - Digamos que el 3.62 funciona pero el 3.63 no. Por tanto, si hacemos diff -r, y pasamos como argumentos los directorios de las dos versiones, obtenemos una lista con los directorios que cambiaron de una versión a otra. Para cada uno de esos directorios hacemos lo siguiente: Copiamos el directorio, que no es el directorio de trabajo actual, al directorio de trabajo como "dir.63", y lo hacemos consecutivamente con cada directorio. Primero, intentamos mover el directorio de trabajo a "dir.62" y, a continuación, se mueve "dir.63" a "dir". Es decir: mv dir dir.62 mv dir.63 dir find dir 'name '*.[oa]' -print | xargs rm -f Tras esto, volvemos a compilar y probar. Suponiendo que todos los cambios relacionados se encontraban en el subdirectorio, con estas operaciones se habrá conseguido aislar la modificación al directorio. Problemas: es posible que se hayan ocasionado cambios en los archivos de cabeceras. A mí me ha ocurrido esto y dichos cambios fueron bastantes específicos y claros, sin embargo quizás quieras abandonar si te ocurre esto. . Reduciendo la localización a un archivo: - Podemos aplicar la misma técnica, para cada archivo que hay en el directorio, esperando que los cambios en dicho archivo sean intrínsecos. . Reduciendo la búsqueda a una rutina: - Se puede manipular el archivo viejo y el nuevo para, manualmente, crear un archivo que sea resultado de la mezcla de los dos. Este archivo tendría: #ifdef VER62 rutina() { ... } #else rutina() { ... } #endif Después de esto, navegar por el archivo con una rutina cada vez y anteponerla con: #define VER62 /* se colocan aquí ambas rutinas */ #undef VER62 A continuación compilamos otra vez, probamos y movemos los ifdef hasta que encontremos el que marca la diferencia. Por último, enviamos a la persona encargada de mantener esa sección toda la información recabada: las versiones del núcleo, la descripción del fallo y la precisión alcanzada en la localización del mismo. En caso de que se haya conseguido una buena localización no es una mala idea enviar un mensaje a linux.dev.kernel. Si se consiguió reducir el fallo hasta una rutina, probablemente se conseguirá una corrección del fallo en veinticuatro horas. Pido disculpas a Linus y al resto de hackers del núcleo por describir esta aproximación por fuerza bruta que, casi con toda seguridad, no haría ningún hacker del núcleo. Sin embargo, funciona y permite a las personas que no son hackers ayudar a corregir fallos. Además es fascinante porque las instantáneas de Linux permiten hacer esto, cosa que no se puede hacer con los productos que ofrecen los vendedores. Traducido por Alfredo José Muela Romero para el proyecto NuLies.