La pregunta es: ¿tienes el tiempo suficiente para encontrarla? :-).
Me he encontrado con varios casos poltergeist en Linux (últimamente con Debian, en la universidad) y hasta ahora siempre he/hemos encontrado una explicación más o menos convincente a los mismos: armados, eso sí, con el gdb, el strace y el código del kernel para añadir algunos printk() y código de prueba en las syscall implicadas.
Si lo que falla es un programa de usuario, lo mejor es compilarlo de nuevo con símbolos de depuración, enlazarlo estáticamente pasarlo por el depurador. Ojo, que si la aplicación es de kde3.x, la mecánica es un poco distinta por la forma que tienen de cargar por defecto estas aplicaciones: cuando arrancas kmail (por decir algo), éste informa en un pequeño preambulo a kdeinit, que se desdobla y ejecuta como un hijo a kmail. Lo más fácil que se puede hacer es recompilar pasando de kdeinit (como total, tienes que recompilar para añadir símbolos de depuración...).
A partir de ahí está chupado ver el punto exacto dónde falla. Si aún viendo el punto del error, seguimos sin tener claro el porqué (la operación parece legítima, los parámetros que se le pasan a la syscall parecen correctos, etc), toca mirarlo desde dentro del kernel, a ver que narices está fallando.
Aquí empieza lo divertido: ¿cómo pones un punto de ruptura en una syscall del kernel? :-). Si tienes soporte para /proc/kcore y un kernel con símbolos de depuración puedes echar un vistazo a algunas estructuras internas, pero no tienes oportunidad de poner puntos de ruptura.
Tienes parches como kgdb que te permiten depurar un kernel con gdb en remoto, a traves de la línea serie, pero claro: necesita dos máquinas (la de prueba y desde la que depuras) conectadas por el puerto serie, y si tienes una SPARC pues no vas a ningún sitio porque el parche es exclusivamente para x86.
Es más, te puedes encontrar con que el kgdb no te sirva para nada, por la naturaleza del error. Hace poco por ejemplo tuvimos un poltergeist con el kernel 2.2.20 y el 2.4.18 corriendo en un 486 dx2 66, con dos tarjetas de red pnp isa y controladora y discos SCSI: cuando arrancabas con el 2.2.x funcionaban los dos puertos serie pero no las tarjetas de red y cuando arrancabas el 2.4.x funcionaban las dos tarjetas pero no los puertos (sin tocar nada al cambiar de uno a otro). Por si sientes curiosidad, ese lo sacamos ;-) pero kgdb no hubiera servido de mucho.
Otra herramienta más sofisticada (y molona :-)) es UML (User Mode Linux), que te permite correr un sistema Linux en espacio de usuario, en su propia VM. Ahí puedes poner puntos de ruptura o lo que quieras, sin romper nada (otra ventaja es que con UML también puedes hacer un perfilado de tu código en espacio de kernel =8-)). El problema es el de siempre: sólo para Linux/x86, aunque hay un proyecto para portarlo a Linux/SPARCv9 aquí
... Y al final siempre te queda el poner unos cuantos printk(), quizás forzar un oops, recompilar el kernel, reiniciar y probar a ver.
En fin, que si tienes tiempo, en Linux sacas la explicación de todos los problemas, aunque ya te adelanto que si el fallo es muy, muy, muy raro el 99.9% de las veces llegarás a la conclusión de que se trata de un problema de hardware (una tarjeta de red que se reseta aleatoriamente, el orden en el que se testean dos periféricos en conflicto, módulo de memoria erroneo, etc).
Ahora, ¿qué pasa con ese maravillos Windows XP?. Nada, no pasa nada: como algo falle "inexplicablemente", estás muerto. SoftIce ayuda pero no hace milagros así que, en condiciones normales, no vas a poder rastrear el error mucho más alla de la pared de bibliotecas dinámicas sin símbolos de depuración del propio Windows
Resumiendo: Windows es frustrante de cara a buscar la causa de los problemas. Mientras todo te vaya bien, seguiras hablando maravillas de Windows XP pero ¡huy como te encuentres con un poltergeist! :-D
[ Padre ]
|
