Chapter 5. ¡¡¡¡¡¡¡¡Ayuda!!!!!!!!

Table of Contents
Ayuda General.
Problemas Específicos de Compilación
Problemas con el Runtime

Incluso aunque hayas seguido todas las instrucciones al piede la letra, algunas veces surgen problemas imprevisibles. Cualquier cosa puede ir mal, desde un malentendido en las instrucciones, *** ¿debido a la traduccion ... :) ? comentario personal de javi *** 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.

Ayuda General.

Aquí estan las cuestiones más generales que surgen a menudo. Los problemas específicos se tratarán más adelante, en este capítulo.

Algo no funciona, estoy confundido, ¿qué hago?

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 estás, las instrucciones sobre como suscribirte se dieron anteriormente . Ahora, cuando pidas ayuda en la GNOME-list, da muchos detalles . Escribir***Posting " El panel no funciona, ¡esto es una mierda! ***The panel doesn't work, this sucks! " no 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 foo del Foot menu, el panel entero desaparece de repente; ****Whenever I select the foo item from the Foot menu, the entire panel disappears suddenly; 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 clase de sistema usas? No, no todo el mundo tiene el mismo sistema operativo que tú. Necesitamos el tipo de procesador: Sparc, MIPS, i386 (esto incluye Pentiums, AMD, Cyrix, etc), PPC, Alpha, ARM, 680x0, et al; ***¿que es el "et al" anterior?*** 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. *****we need some relevant vital statistics of what is on your system. 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 surgiera 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. **** messages on it, you want yours to stand out to the people you need help from, and be safely passed over by people who can't help. Un subject como "GNOME está roto" es candidato a ser ignorado; uno como "GSM es una mierda (sucks)" pondrá a la gente de malas, y no con 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, *** se refiere a "atenta" o a "meditada"*** thoughtful response. Si por algún motivo no obtienes una rápida respuesta, no te lo tomes como algo personal, probablemente el mail se perdión en el montón. ***the mail probably just got lost in the volume. 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.

¿Cómo informo de un bug?

Si encuentras un bug, queremos saber sobre él, 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 al enviar bugs al sistema. Primero asegúrate de comprobar la página ****to check the web front end at 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 ***headings*** 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. ****You also can track the status of the bug through the bug tracking system's web front end.

**** Esta pregunta deberia ser contentada antes de la seccion de compilacion ya que alli aparece y yo no sabia lo que era*** ¿Qué es un prefix (o un $prefix, ${PREFIX}, o <prefix>)?

Cuando se compila GNOME, necesitas especificar donde se situará en el sistema de archivos. La opción específica para usar esto se llama --prefix , por lo que la llamamos the GNOME Prefix, o 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), ****but never gave configure (or autogen.sh ) a prefix, por defecto es /usr/local . Si instalaste los RPMS de RedHat, estos usan el prefix /usr . Si todavía no estás seguro, escribe which panel , y quita /bin/panel del final. Lo que queda es tu prefix.

¿Qué significa ***Segmentation Fault ?

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) *****(often called segments), 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 " 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. ****What it all boils down to is there is a bug in whatever program you were running. 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.

¿Qué es un core dump? ¿Qué es este fichero llamado core que no paro de encontrarme? ***What is this file named core that I keep running into?

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. *****In the early days of electronic computers, computer memory was a bunch of magnetic rings called cores, mounted on wires. This type of memory was called core memory. When a programmer wanted to see what was going on in their program, they would output a copy of what was in their core memory so they could analyze it. This output was called a core dump, and the term has remained long after core memory became obsolete.

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). ***This file is very useful for debugging why the program failed, and can be used to produce a backtrace (see below). Por otra parte, este fichero puede ser bastante grande, particularmente si no lo usas para el debugging. ***this file can be quite large, particularly if you aren't using it for debugging. Su no puedes permitirte tener core dumps, consulta la documentación de tu sistema para averiguar como desabilitar esta característica.

¿Qué es un backtrace? Alguien me pidió que le enviara uno, ¿cómo lo hago?

Una herramienta de debugging incleiblemente útil es el backtrace. En esencia es un ***snapshot of exactly where in the program you are. Se realiza más a menudo cuando un programa ***crashes (cierra inesperadamente, a menudo con un segmentation fault u otro error) o ***hangs (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 crashed, 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. ***I have found that running the program within the debugger is more reliable, but I will discuss using core files as well.

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. ***You can specify command like arguments later.

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 ****to debug gtalk with sound disabled, you would type 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. ***Do whatever it is that caused the problem before. Una vez que el programa ***crashes, deberías ver inmediatamente el material en la sesión de debug, y un prompt ***Once the program crashes, you should immediately see stuff in the debug session, and a (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 material de debugging, seguida de un prompt ***It too should reply with a bunch of stuff, followed by a (gdb) . En este prompt (sea cual sea la forma en que llegaste), escribe bt . Entonces respoderá con el backtrace propiamente dicho. Then it will reply with the actual backtrace.

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.

¿Qué es una strace? Alguien me pidió que le enviara una, ¿cómo lo hago?

El comando strace realiza una "Signal Trace". ******Using it will allow you to run a program while outputting system calls and signals. This is a much more verbose debugging tool than the backtrace, but sometimes you need the extra information an strace can give you. 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 ***to do an strace on the gtalk program with sound disabled, I might do 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.

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 *****Warning, strace produces lots of output (the above strace example came up with 5,498 lines in five seconds). Don't send straces to the mailing lists, and only send them to the developers if they specifically request it.

En sistemas Solaris, el comando strace hace algo diferente. El comando truss es probablemente lo que espere la persona que te pidió el strace.