Incluso aunque hayas seguido todas las instrucciones al pie de la letra, algunas veces surgen problemas imprevisibles. Cualquier cosa puede ir mal, desde un malentendido en las instrucciones, a un bug en el software, o un bug en el software de otra persona. Aquí, intentamos hacer frente a problemas que han tenido con GNOME algunas personas.
Aquí se recogen las cuestiones más generales que surgen a menudo. Los problemas específicos se tratarán más adelante, en este capítulo.
Bueno, lo primero que debes hacer es una pausa, relájate, y respira profundamente. Seguidamente, revisa estas FAQ, la Guía de Usuario, y cualquier otra documentación que tengas a mano y mira a ver si alguna se aproxima a la resolución de tu problema. Lo siguiente es mirar en los archivos de la lista de correo (las instrucciones se dieron anteriormente ) para ver si alguien más ha comentado algo sobre tu problema. Después prueba a ver, sea lo que sea lo que estabas haciendo una vez más , si la solución de repente aparece por si misma. Si nada de eso funciona, es hora de preguntar en la lista.
Antes de nada, estás suscrito a la gnome-list, ¿verdad? Si no lo estás, las instrucciones sobre como suscribirte se dieron anteriormente . Ahora, cuando pidas ayuda en la GNOME-list, da muchos detalles . Escribir " El panel no funciona, ¡esto es una mierda! " no nos ayuda ni a tí ni a nosotros. Aun tendrás el mismo problema, y nosotros tendremos un posible bug del cual no tendremos información. Es más útil (pero todavía insuficiente) decir " Cada vez que selecciono el lo-que-sea del menu principal, el panel entero desaparece de repente; por cierto, ¿qué es este fichero que GNOME no deja de poner en mi directorio personal, y que se llama core ?. "
Lo ideal, es que tengamos cierta información necesaria sobre tí. Lo primero, exactamente ¿que tipo de sistema operativo usas? No, no todo el mundo tiene el mismo sistema que tú. Necesitamos el tipo de procesador: Sparc, MIPS, i386 (esto incluye Pentiums, AMD, Cyrix, etc), PPC, Alpha, ARM, 680x0, et al; necesitamos el sistema operativo: distribución Linux, FreeBSD, HURD, OpenBSD, Solaris, IRIX, CrayOS, OS/400, o lo que sea. También incluye la versión del sistema operativo. Por ejemplo, la máquina en la que estoy ahora mismo es una GNU/Linux RedHat/i386 Rawhide machine, un amigo mio usa una máquina Solaris Sparc 2.6.
Seguidamente, necesitamos algunas vitales y relevantes estadísticas de que hay en tu sistema. En un sistema GNU/Linux, el número de versión del kernel y de libc son casi siempre importantes. En la mayoría de problemas de GNOME necesitamos las versiones de glib, gtk+, Imlib, ORBit y gnome-libs. Si no estás seguro si necesitas algunas de las anteriores, inclúyelas de todas formas. Otras cosas que a veces son importantes son las versiones de Perl, X11, Python, Guile y libpng, a menos que veas un mensaje de error que mencione alguna, puedes no incluirlas. Otra cosa importante es cómo instalaste GNOME. ¿Usaste binarios?, si es así ¿cuáles? ¿Usaste tarballs? ¿Usaste el CVS?, si es así que fechas y/o tags? Si usaste una mezcla de los anteriores, menciónalo también.
Por último, necesitamos el problema en sí. Necesitamos saber exactamente qué hiciste para que apareciese el problema. Necesitamos saber si el problema es permanente o intermitente. Necesitamos saber si el programa mostró algo con altelación al problema. Necesitamos saber exactamente que sucede cuando ocurre el problema. Si quieres ser ambicioso, prueba con algunas herramienta de diagnostico de las que hablo más adelante, como backtrace, e incluye esa información en el mail.
Ahora antes de te prepares para mandar el correo, necesitamos encontrar un buen subject. La Gnome-list suele puede tener muchos mensajes, y tú quieres que el tuyo resalte que necesitas ayuda, y que pase desapercibido entre la gente que no pueda ayudar. Un subject como "GNOME no funciona" es candidato a ser ignorado; uno como "GSM es una mierda (sucks)" pondrá a la gente de malas, y con pocas ganas de ayudar; algo como "La mayoría de los iconos del panel en HP-UX son sólo cuadros negros" es más probable que tenga la clase de atención que necesita.
Pon todo esto junto en un correo electrónico largo y envíalo a la lista. Si seguiste mi consejo, es muy probable que obtengas una rápida, y meditada respuesta. Si por algún motivo no obtienes una rápida respuesta, no te lo tomes como algo personal, probablemente el mail se perdió entre la masa. Espera un par de días, mira a ver si puedes añadir algún detalle, o una quizás una cabecera más descriptiva, y envíalo otra vez.
Si encuentras un bug, queremos conocerlo, queremos seguirlo, y queremos arreglarlo. Para hacer este proceso lo más eficiente posible, hemos tomado prestado de Debian su excelente sistema de seguimiento de bugs. Instrucciones completas sobre como utilizarlo en http://bugs.gnome.org/Reporting.html .
Hay unas pocas cosas que hay que tener en cuenta antes de enviar bugs al sistema. Primero asegúrate de comprobar la página http://bugs.gnome.org para asegurarte de que tu bug no se conoce todavía en el sistema. Si es un nuevo bug, envíalo a submit@bugs.gnome.org . Asegúrate de que incluyes las cabeceras del Paquete y Version como se describe en las instrucciones, esto asegura que será dirigido rápida y automaticamente a la persona adecuada. Asegúrate que incluyes todos los detalles. Mira la cuestión previa para tener una idea de lo que es útil incluir. Si un backtrace o strace es apropiado, desde luego que lo has de incluir. Las instrucciones sobre como hacer esto se dan más adelante.
Después de que envies el bug al sitema. Obtendrás comentarios sobre el bug via email. También puedes seguir la evolución del bug mediante el sistema de seguimiento de bugs en formato web.
Cuando compilas GNOME, necesitas especificar donde se situará en el sistema de archivos. La opción específica para usar esta característica se llama --prefix , por lo que la llamamos el prefijo de GNOME , o prefijo (prefix) para abreviar. La localización de los archivos de GNOME debería ser la misma de un sistema a otro, excepto por el prefijo, por lo que un archivo en /usr/share/gnome/pixmaps en un sistema podría estar en /opt/gnome/share/gnome/pixmaps en otro, y nos referiríamos a la localización como $prefix/share/gnome/pixmaps .
Si instalaste desde tarballs (o CVS), pero nunca les pasaste a configure (o a autogen.sh ) un prefijo, por defecto es /usr/local . Si instalaste los RPMS de RedHat, estos usan el prefijo /usr . Si todavía no estás seguro, escribe which panel , y quita /bin/panel del final. Lo que queda es tu prefix.
La mayoría de sistemas Unix y similares tienen una característica llamada protección de memoria. Esto significa que un programa puede acceder a algunas partes de la memoria (a menudo llamadas segmentos), pero no a otras. Si el programa intenta acceder a una zona fuera de los segmentos que tiene permitidos, el sistema detecta el problema y muestra un error. Este error se denomina un Segmentation Fault (abreviado " segv " en algunos sistemas), y generalmente, el programa se cerrará de repente, normalmente dejando tras de sí un core dump (ver bajo).
Todo esto se reduce a la existencia de un bug sea cual sea el programa que estabas ejecutando. El bug podría estar en el código fuente de GNOME, podría estar en las librerías compartidas que usa tu programa, o podría estas en el modo en que se compiló el programa. Si no estás seguro si es un bug en GNOME o en otra parte, pregúntalo en la lista. Si estás seguro que el bug recae en GNOME, por favor asegúrate de que está en el sistema de seguimiento de bugs.
En los primeros días de los ordenadores electrónicos, la memoria de los ordenadores era un manojo de aros magnéticos llamados cores, montados sobre cables. Este tipo de memoria se llamaba memoria core. Cuando un programador quería ver lo que estaba pasando en su programa, extraía una copia de lo que había en la memoria core para así analizarla. Esta copia se llamaba un core dump, y el término ha permanecido hasta mucho después de que las memorias core se quedaran obsoletas.
En muchos sistemas Unix y similares, el sistema producirá automaticamente un core dump cuando un programa falle catastroficamente, por ejemplo cuando se produce un Segmentation Fault (ver arriba). Generalmente pone el core dump en un fichero llamado core en el directorio donde estuvieras cuando ejecutaste el programa. Este fichero es muy útil para hacer un debugging y saber por qué fallo el programa, y puede ser usadoo para producir un backtrace (ver abajo). Por otra parte, este fichero puede ser bastante grande, particularmente si no lo usas para el debugging. Su no puedes permitirte tener core dumps, consulta la documentación de tu sistema para averiguar como desabilitar esta característica.
Una herramienta de debugging incleiblemente útil es el backtrace. En esencia es una toma de donde estas exactamente en el programa.Se realiza normalmente cuando un programa "crashes" (cierra inesperadamente, a menudo con un segmentation fault u otro error) o se cuelga (deja de funcionar pero no se cierra). En esta respuesta, voy a tener que asumir que estás usando el debugger GDB del proyecto GNU, ya que ese es el más común incluido con GNOME, y el que yo he usado. Si usas otro debugger, consulta tu documentación.
Hay dos maneras de hacer un backtrace. Puedes usar un archivo core que dejó un programa cuando se cerró, o puedes ejecutar el programa desde el debugger. La experiencia me demuestra que ejecutar el programa desde el debugger es más seguro, pero también comentaré como usar los archivos core.
Para ejecutar un programa dentro de GDB, ve a un xterm (o equivalente), y teclea gdb <nombre completo y localización del programa> , por ejemplo, para hacer un debug sobre gtalk, deberías hacer ***to debug gtalk, you might do gdb /usr/local/bin/gtalk . GDB no busca el path, por lo que tienes que especificarle donde está el progama. Si quieres ejecutar el programa con argumentos, no los pongas aquí . Puedes especificar argumentos de linea de comando después.
GDB se identificará, y mostrará un prompt (gdb) . Desde aquí, escribe run para arrancar el programa. Si quieres ejecutar el programa con argumentos, ponlos aquí. Por ejemplo, para hacer un debug sobre gtalk con el sonido desactivado, deberías escribir run --disable-sound . Entonces el programa arrancará. Ten presente que el programa irá más lento de lo normal, y usará mucha memoria.
Ahora intenta recrear el problema que tuviste. Haz lo que fuera que hicieres para causar el problema anterior. Una vez que el programa cierre (por crash), deberías ver inmediatamente algo en la sesión de debug, y un prompt (gdb) . Si el programa se cuelga, espera hasta estar seguro de que se colgó en el lugar correcto, y entonces aprieta Control-C en la sesión de debug. Tambíen aquí debería aparecer algo de debugging, seguido de un prompt (gdb) . En este prompt (sea cual sea la forma en que llegaste), escribe bt . Entonces respoderá con el backtrace propiamente dicho.
Aquí tienes un ejemplo de una sesión de debug. Si te piden un backtrace, deberías enviarlo todo:
$ gdb /usr/local/bin/gtalk GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run --disable-sound Starting program: /usr/local/bin/gtalk --disable-sound Program received signal SIGINT, Interrupt. 0x4049290d in __poll (fds=0x808c110, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:45 ../sysdeps/unix/sysv/linux/poll.c:45: No such file or directory. (gdb) bt #0 0x4049290d in __poll (fds=0x808c110, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:45 #1 0x403c54e9 in g_main_poll (timeout=-1, use_priority=0, priority=0) at gmain.c:991 #2 0x403c516e in g_main_iterate (block=1, dispatch=1) at gmain.c:789 #3 0x403c58a1 in g_main_run (loop=0x80882e8) at gmain.c:912 #4 0x401cbf1d in gtk_main () at gtkmain.c:475 #5 0x804a629 in main (argc=2, argv=0xbffffaa4) at main.c:54 #6 0x40407c77 in __libc_start_main (main=0x804a570 <main>, argc=2, argv=0xbffffaa4, init=0x8049e10 <_init>, fini=0x804c7dc <_fini>, rtld_fini=0x40009c10 <_dl_fini>, stack_end=0xbffffa9c) at ../sysdeps/generic/libc-start.c:78 (gdb) |
Hacer un backtrace con un core dump es muy parecido. Ve al directorio donde está el core dump, y entonces ejecuta gdb -c core <nombre completo y localización del programa> . De nuevo, GDB no mira en tu path, tienes que especificarle donde encontrar el programa. Todo lo que tienes que hacer es escribir bt en el prompt, y enviar la sesión entera.
El comando strace realiza una "Signal Trace". Usarlo te permitirá ejecutar un programa mientras obtienes las señales y llamadas del sistema. Esta es una herramienta mucho más de debugging tipo "verbose" que el backtrace, pero algunas veces necesitas información extra que un strace puede darte. Obtener un strace es fácil, simplemente escribe strace -o <archivo de salida> <comando con argumentos> en un xterm. Por ejemplo, para hacer un strace al programa gtalk con el sonido deshabilitado, yo haría strace -o /tmp/gtalk.strace gtalk --disable-sound . Esto guardaría la salida del strace en /tmp/gtalk.strace . Strace sí que usa el path, y acepta argumentos de programa en la linea de comandos.
Una advertencia. Strace produce una gran salida (con el anterior ejemplo de strace se obtuvieron 5.498 lineas en cinco segundos). No envies straces a las listas de correo, y solamente envíaselas a los desarrolladores si te las piden especificamente
En sistemas Solaris, el comando strace hace algo diferente. El comando truss es probablemente lo que espere la persona que te pidió el strace.