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)
Ojito a quien la pruebe... (3.00 / 3) (#1)
por Zephryn Xirdal (zephrynxirdal(ARROBAR_A)telefonica.net) a las Thu Jan 2nd, 2003 at 08:43:25 PM CET
(Información Usuario)

Pues eso, que ojito y esperaros cosas de lo más extrañas (como que un paquete falle al compilar ahora sí, pero dentro de un rato no, que algo pete sin explicación posible, etc... etc...). Para quien quiera una muestra, que consulte mi diario. Lo siento, pero ahora soy muy, pero que muy feliz con mi XP Home Original.



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 ]


 
El filo de la navaja (3.33 / 3) (#9)
por Tomby (tomby@QuItAeStOtomby.tkNoSpAm) a las Sat Jan 4th, 2003 at 04:07:45 PM CET
(Información Usuario) http://www.tomby.tk/

Yo he utilizado Gentoo, creo que la versión 1.2, y la verdad es que me gusto mucho. Por supuesto, si no tienes como minimo una conexión ADSL o cable, puede llegar a ser desesperante.

Eso de compilar los paquetes optimizados para tu plataforma y poder tener lo último de lo último me encantó.

Pero eso supone un monton de problemas de estabilidad, problemas de compilación, incompatibilidades entre versiones actuales de un paquete y paquetes ya instalados que dependen de ese paquete, en fin, lo que es vivir al filo de la navaja.

Si lo que buscas es estabilidad, Gentoo no es para tí. Prueba con Debian Woody y verás lo que es estabilidad a prueba de bombas.

Saludos y feliz año.

[ Padre ]


 
Argh... blasfemia :-) (3.00 / 3) (#2)
por suy (suy21.existe-en.lycos.es) a las Fri Jan 3rd, 2003 at 12:37:29 AM CET
(Información Usuario) http://lacurva.net/

Lo siento, pero ahora soy muy, pero que muy feliz con mi XP Home Original.

Argh... blasfemia :-)

Puestos a tener más de un sistema operativo, yo lo intentaría con 2 distribuciones de linux. Es siempre una buena idea, y son fácilmente personalizables. Reconozco que yo tengo un windows también por ahí, pero solo lo toco cuando tengo que usar algún software muy concreto de la universidad (algo que hizo un proyectista, y que es una aplicación muy muy concreta).

Y si no... para eso está knoppix como disco de rescate (o el live-cd que prefiráis).

Un saludo.


Esto será mi vida, porque es lo único importante en ella.
Y, si fracaso, moriré, porque para mí no existe nada más.

Raistlin Majere
[ Padre ]


 
Opciones de compilación (3.00 / 2) (#4)
por ochoto (ochoto_@_diariolinux.com) a las Fri Jan 3rd, 2003 at 04:31:21 PM CET
(Información Usuario) http://diariolinux.com

Hola Zephryn, yo también he sufrido algún contratiempo por fallos de compilación pero todos menos uno se debían a haber tocado las opciones de optimización del compilador, en cuanto puse las opciones básicas todo compilo de maravilla (salvo el paquete unixODBC que tiene algún problema).

El caso es que el gcc 3.2 falla más que una escopeta de feria en cuanto le pones algo más que -march=micpu -O3 -pipe y digo yo que si las optimizaciones nuevas no funcionan es como si no estuvieran. En fins, espero que la cantidad de bug reports que les van a llegar por las distribuciones "source-based" aceleren la depuración :)




[ Padre ]


¿Qué opciones del gcc3.2 son las que no van? (3.00 / 2) (#5)
por jorginius ("jorginius" en Google Mail) a las Fri Jan 3rd, 2003 at 05:33:41 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

¿Y cuál es tu arquitectura?. Estoy usando habitualmente el nuevo soporte para SSE en un PIII y aún no he encontrado ningún problema :-?

[ Padre ]


omit-frame-pointer y optimize-sibling-calls (3.33 / 3) (#6)
por ochoto (ochoto_@_diariolinux.com) a las Fri Jan 3rd, 2003 at 06:02:23 PM CET
(Información Usuario) http://diariolinux.com

Concretamente esas dos opciones tuve que quitar para que compilara todo correctamente. Mi arquitectura es i86 y las opciones me han quedado tal que:

-march=athlon-4 -O3 -pipe

Como me petaba en kdelibs y tarda unas horitas en compilar no he vuelto a hacer la prueba de compilar con cada una de las problemáticas para ver si la culpable era la primera, la segunda, ambas o las dos combinadas :))

En cualquier caso apuesto por omit-frame-pointer ya que según veo en http://www.freehackers.org/gentoo/gccflags/faq.html es la única que se activa condicionalmente (#ifdef CAN_DEBUG_WITHOUT_FP)



[ Padre ]


El malvado flag fomit-frame-pointer (4.00 / 2) (#7)
por jorginius ("jorginius" en Google Mail) a las Fri Jan 3rd, 2003 at 07:50:07 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

En cualquier caso apuesto por omit-frame-pointer ya que según veo en http://www.freehackers.org/gentoo/gccflags/faq.html es la única que se activa condicionalmente (#ifdef CAN_DEBUG_WITHOUT_FP)

Pues vas a tener razón porque he visto por Google un porrón de referencias de aplicaciones del KDE que fallan con el fomit-frame-pointer... Y mira que me extraña que los tiros vayan por ahí. Gracioso, muy gracioso 8-).

Hasta donde yo sé (o "sabía") fomit-frame-pointer es una opción segura y que no es incluida en las optimizaciones éstandar de x86 sólo porque hace imposible la depuración. Incluso es una de las opciones por defecto al compilar el kernel. Además cuando escribo un procedimiento en ensamblador a mano tampoco suelo cambiar puntero base de la pila si no voy a llamar a nada después y "aún" no me ha fallado :-)

Quizás sea sólo un problema con KDE, por la forma especial que tiene de cargar las aplicaciones y resolver los símbolos. Me tiene intrigado :-): uso habitualmente el fomit-frame-pointer en las versiones finales, con gcc3.2, y todavía no me he tropezado con un fallo de estos.

En todo caso, no es un problema de Gentoo sino del KDE o del compilador. Es más, en Gentoo acabo de encontrar lo siguiente en el koffice-1.2_beta2.ebuild (parece ser la plantilla de compilación del koffice):

#the dir kchar/kdchart cannot be compiled with the -fomit-frame-pointer flag present
kde_remove_flag kchart/kdchart -fomit-frame-pointer
kde_remove_flag kugar/kudesigner -fomit-frame-pointer # bug 4572

O sea, que en Gentoo son conscientes de que eso del "fomit-frame-pointer" no va con KDE siempre y hacen salvedades para evitarlo.

[ Padre ]


Es gcc, tambíen peta al compilar ruby (3.00 / 2) (#10)
por ochoto (ochoto_@_diariolinux.com) a las Sat Jan 4th, 2003 at 04:23:28 PM CET
(Información Usuario) http://diariolinux.com

Hoy me ha vuelto a pasar al compilar ruby, he quitado el -fomit-frame-pointer "et voilá". Supongo que lo solucionaran para la próxima versión de gcc

[ Padre ]


¿El error te lo da al compilar? (3.00 / 2) (#11)
por jorginius ("jorginius" en Google Mail) a las Sat Jan 4th, 2003 at 06:52:01 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Hoy me ha vuelto a pasar al compilar ruby, he quitado el -fomit-frame-pointer "et voilá"

... ¿O al ejecutar? :-?

Es que no soy capaz de reproducir el fallo (ok, sin Gentoo :-P): acabo de compilar ruby con fomit-frame-pointer en el PIII de cacharreo sin problemas y por lo que he visto se ejecuta bien (???).

$ gcc -dumpversion
3.2.1

En concreto uso, directamente del repositorio de gcc: "gcc version 3.2.1 20021207".

¿Tienes aislado el error en algún archivo concreto?, ¿qué compilador y binutils utilizas?, ¿puedes enviarme más info y una copia del código asm que genera el gcc?: mi dirección de correo es:
jorginius En users.sourceforge.net

[ 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