Hace un año, los desarrolladores del kernel Linux descubrieron que la versión 6.2 (y algunas de las posteriores) de éste contaba con un bug que provocaba que el arranque se bloquease, aproximadamente, una de cada 1000 veces, sin razón aparente.
Pero sólo lo descubrieron gracias a que un desarrollador de Red Hat (aunque trabajando a título individual) estuvo dispuesto a iniciar y reiniciar sus máquinas más de 300.000 veces para localizar el problema, primero, y verificar que el problema había sido adecuadamente localizado, después.
Richard WM Jones explica en su blog que decidió emprender esta ardua labor porque detectó que las pocas veces que pocas veces que experimentaba cuelgues sin razón aparente usando nbdkit (un servidor que permite acceder a discos en la nube), sus máquinas virtuales basadas en qemu se colgaban siempre al llegar al mismo punto del arranque:
[ 0.070120] Freeing SMP alternatives memory: 48K
"Me sorprende que nadie haya notado esto", explica. Pero él, ni corto ni perezoso, decidió realizar recurrir a la herramienta 'bisect' de Git para resolver el misterio.
Un inciso: ¿Qué es eso de 'bisect'?
Localizar bugs forma parte del día a día de cualquier programador, pero no siempre son fáciles de encontrar entre multitud de líneas de código y de commits (incorporaciones de cambios en el código) en Git. Por fortuna, hay un comando de Git que facilita la tarea: 'git bisect'.
Éste permite al desarrollador delimitar un abanico de opciones entre los últimos commits que consideramos seguros y los que sabemos que ya presentaban el fallo, y revisar más fácilmente los que quedan en medio, realizando para ello búsquedas binarias.
Sigamos…
Sabiendo eso, prosigamos con la narración de Jones. Si quería poder recurrir al bisect, tenía que recurrir previamente a la herramienta guestfish "y ejecutarla en bucle para recopilar 'cuelgues'. ¿Cuántas veces? Elegí 10.000 arranques como un buen umbral".
Después de una "dolorosa bisección" (es decir, de una sesión de uso del bisect de Git) entre las versiones v6.0 y v6.4-rc6 del kernel que le "llevó muchos días", pudo encontrar al culpable: una regresión en la característica printk time.
Aunque inicialmente, y "por razones poco claras, el bisect señalaba un commit merge" —es decir, a una combinación de numerosos commits incorporados simultáneamente al código del kernel—.
"Así que tuve que probar manualmente cada commit dentro del mismo, lo que me llevó aproximadamente otro día más".
"Pero eso no bastaba. Para probarlo arranqué Linux 292.612 veces versiones previas al commit defectuoso (con éxito), y posteriores al mismo (falló tras menos de 1.000 arranques)".
Su labor fue aplaudida por otros usuarios, tanto en los comentarios de su propio blog como en Twitter:
Es un trabajo detectivesco excepcional.
Impresionado con la tenacidad de tu búsqueda. Yo habría asumido erróneamente que 1 fallo de cada 1000 se podría atribuir a un mero error aleatorio. Enhorabuena.
Este nivel de compromiso es digno de enmarcarse y colocarse en un pedestal ante una multitud de miles de personas que aplauden en pie.
No todos los héroes llevan capa.
Imagen | Generada mediante IA
En Genbeta | La Fundación Linux ha lanzado un curso gratis para iniciarte en el desarrollo del kernel de Linux
Ver 4 comentarios