Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
Gentoo 1.4 rc2 lanzada | 16 comentarios (16 temáticos, editoriales, 0 ocultos)
Siempre hay una explicación para cada problema (4.83 / 6) (#3)
por jorginius ("jorginius" en Google Mail) a las Fri Jan 3rd, 2003 at 01:23:42 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

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 ]


Ok, pero yo USO el so, no lo REPARO (none / 0) (#13)
por Zephryn Xirdal (zephrynxirdal(ARROBAR_A)telefonica.net) a las Sat Jan 11th, 2003 at 02:52:42 PM CET
(Información Usuario)

En eso estoy de acuerdo, pero el problema para mi es que el ordenador es una herramienta, no un fin, y no quiero enredarme en esos problemas. Programo, pero programo hardware -micros Hitachi y Motorola principalmente-, y eso que tu haces en el PC lo hago yo en las placas que programo. Mismito que tu. Con osciloscopio, analizador lógico (aunque me da pánico cogerlo), y polímetro. Y grandes -muy grandes- dosis de imaginación e improvisación (y si no, haz que un 5206e tenga la bondad de arrancar y no dar por culo, y que cuando actives un DMA no se joda una UART), amén de las pejiguerías de los compiladores de C/C++ (el CodeWarrior no trabaja bien con campos de bits, y a veces se olvida de enlazar algunas variables, sobre todo si son punteros a punteros y cosas así , al gnu para 52xx a veces se le olvida recuperar bien la pila cuando retorna de una función cuando empleas un valor superior a -O0, etc).

Y desde luego que cuando el windows falla lo tienes crudo, muy crudo.

[ Padre ]


Pues ahí está (none / 0) (#14)
por jorginius ("jorginius" en Google Mail) a las Mon Jan 13th, 2003 at 10:47:05 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Alguien lo tiene que reparar. Si tú no lo haces porque no es tu trabajo otro tendrá que hacerlo por ti para que puedas trabajar, e igual que tú aprecias el osciloscopio, el panoli que se tiene que pegar con el software agradece que le den las fuentes de TODO y tener herramientas adecuadas con las que tratarlas.

Por si acaso no queda claro: que no te estoy diciendo "si te falla es que eres gili* por no arreglarlo". Sólo te digo que las cosas se pueden arreglar en Linux, y en WinXP pues a lo mejor sí o a lo mejor no (y en todo caso te exige tener el doble de conocimientos, no cabrearte fácilmente y que te dé igual que la mitad de cosas que estás probando sean ilegales).

Ahora que lo pienso, a lo mejor me puedes echar un cable. Verás: este año me han encargado la programación de nuestro microrobot de concurso. Usamos un (bueno, en realidad son varios pero es muy largo de explicar :-)) PICs (PIC16F84) y pensábamos meter algo más de memoria y ya pasarnos del ensamblador al C como lenguaje de programación ¿Conoces algún compilador bueno para ese PIC (preferiblemente gratuito y para Linux)?. Me han dejado uno pero a) es pirata y b) el código ensamblador que genera es un asco y lo tengo que retocar a mano :-(.

[ Padre ]


Soft. para PICs. (none / 0) (#15)
por Zephryn Xirdal (zephrynxirdal(ARROBAR_A)telefonica.net) a las Mon Jan 13th, 2003 at 10:58:42 PM CET
(Información Usuario)

Pues siento decirte que no conozco ningún compilador para PICs que trabaje en linux. En mi empresa descartamos el uso de los mismos tiempo ha, por motivos un tanto "personales": a nuestro "hardwarero" no le gustan, y si hemos de hacer algo pequeño, pues usamos un J1 de Motorola. Lo que te puedo decir es que uno de los comerciales que nos visitan a menudo nos dijo que los compiladores de los nuevos PIC rondaban las 50K pelas de las de antes (para windoze, eso sí).

[ Padre ]


En SDCC (none / 0) (#16)
por jorginius ("jorginius" en Google Mail) a las Mon Jan 13th, 2003 at 11:04:40 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Tienen algo, pero parece que es sólo para 18F. No sé...

Lo de usar PIC es porque tenemos PIC, como habrás supuesto :-). Además llevamos ya unos cuantos añitos con esos trastos y creo que si ahora que me toca a mí programarlos les digo que cambiamos de hard, me van a mandar a hacer puñetas :-D.

En fin, muchas gracias de todas formas.

[ Padre ]


 

Gentoo 1.4 rc2 lanzada | 16 comentarios (16 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda