53 KiB

Raw Blame History

Traducción Revisón: 1.70

GNU/Emacs 29.1

53 Informar de Fallos
Ver código fuente de la página

53 Informar de Fallos

Si cree que ha encontrado un error en Emacs, por favor, notifíquelo. No podemos prometer que lo arreglaremos, o que siempre estaremos de acuerdo en que es un fallo, pero desde luego queremos oír hablar de él. Lo mismo se aplica a las nuevas características que le gustaría ver añadidas. Esta sección lo ayudará a determinar si ha encontrado un error y, en caso afirmativo, a elaborar un informe de error eficaz.

El procedimiento general cuando encuentras algo que podría ser un bug es el siguiente:

Comprueb3 si lo que ha encontrado es un problema conocido o un fallo del que ya se ha informado y/o solucionado. Vea Lectura de Informes de Fallos Existentes y Problemas Conocidos,

donde encontrará cómo buscar problemas y fallos conocidos.

Si no seguro de si el comportamiento que ve es un bug, consulte Cuándo Hay un Bug, donde se indica lo que consideramos como bugs claros en Emacs.

Una vez que decida que ha encontrado un bug, mira Understanding Bug Reporting, que loa ayuda a describir lo que ve de la manera más eficiente, haciendo nuestro trabajo de reproducir

el problema e investigarlo más fácil.

A continuación, vea Lista de Comprobación para Informes de Fallos, donde describimos en detalle cómo enviar un informe de fallo y qué información incluir en él. En pocas palabras,

envíe un informe de fallo por correo electrónico usando el comando de Emacs report-emacs-bug, que lo ayuda a hacerlo. El envío de un informe de fallo inicia el proceso de investigación y corrección del fallo, en el que recibirá copias de los mensajes de correo electrónico en los que se discute el fallo, en los que podemos pedirle que proporciones más información, que pruebes posibles correcciones, etc.

Finalmente, si quiere proponer cambios específicos a Emacs, ya sea para arreglar un error, añadir una nueva característica o mejorar nuestra documentación, por favor, mire Enviar

Parches para GNU Emacs, para más detalles sobre cómo enviar dichos cambios.

53.1 Lectura de Informes de Fallos y Problemas Conocidos

Antes de informar de un fallo, si es posible, por favor compruebe si ya lo conocemos. De hecho, puede que ya haya sido corregido en una versión posterior de Emacs, o en la versión de desarrollo. Aquí tiene una lista de los principales lugares donde puede leer sobre problemas conocidos:

El archivo etc/PROBLEMS; teclea C-h C-p para leerlo. Este archivo contiene una lista de problemas particularmente conocidos que se han encontrado al compilar, instalar y ejecutar

Emacs, con especial énfasis en problemas causados por otro software que no pueden resolverse fácilmente en Emacs. A menudo, encontrará sugerencias de soluciones.

El GNU Bug Tracker en https://debbugs.gnu.org. Los errores y problemas de Emacs se archivan en el rastreador (o gestor de fallos) bajo el paquete “emacs”. Dicho rastreador registra

información sobre el estado de cada fallo, el informe inicial del fallo y los mensajes de seguimiento del que ha informado del fallo y de los desarrolladores de Emacs que participan en la discusión y corrección del fallo. Para criterios de búsqueda más complejos, use https://debbugs.gnu.org/cgi/search.cgi.

En lugar de navegar por el gestor de fallos como una página web, puede hacerlo desde Emacs usando el paquete debbugs, que puede descargarse a través del menú de paquetes (ver Paquetes Emacs Lisp). Las etiquetas de Usuario, aplicadas por los mantenedores de Emacs, se muestran con M-x debbugs-gnu-usertags.

La lista de correo “bug-gnu-emacs” (también disponible como grupo de noticias “gnu.emacs.bug”). Puede leer los archivos de la lista en

https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs. Esta lista funciona como un espejo de los informes de fallos de Emacs y de los mensajes de seguimiento que se envían al rastreador de fallos. También contiene antiguos informes de errores de antes de que se introdujera el rastreador de errores (a principios de 2008).

Si quiere, puede suscribirte a la lista. Tenga en cuenta que su propósito es proporcionar a los mantenedores de Emacs información sobre fallos y peticiones de características, por lo que los informes pueden contener cantidades bastante grandes de datos; los espectadores no deberían quejarse de esto.

La lista de correo “emacs-pretest-bug”. Esta lista ya no se utiliza, y es principalmente de interés histórico. En un tiempo, se utilizaba para los informes de errores en las

versiones de desarrollo (es decir, aún no publicadas) de Emacs. Puede leer los archivos desde 2003 hasta mediados de 2007 en https://lists.gnu.org/r/emacs-pretest-bug/. Actualmente, los mensajes de correo electrónico enviados a esta lista se redirigen a “bug-gnu-emacs”.

La lista de correo “emacs-devel”. A veces se informa de errores en esta lista de correo. Sin embargo, este no es el propósito principal de la lista, y es mucho mejor enviar los

informes de errores a la lista de errores. No debería sentirte obligado a leer esta lista antes de informar de un error.

53.2 Cuándo hay un Error

Si Emacs accede a una posición de memoria inválida (también conocido como «segmentation faul», fallo de segmentación) o sale con un mensaje de error del sistema operativo que indica un problema en el programa (en lugar de algo como «disk full», disco lleno), entonces es ciertamente un bug.

Si la pantalla de Emacs no se corresponde correctamente con el contenido del búfer, entonces es un bug. Pero deberías comprobar que características como el estrechamiento del búfer (ver Estrechamiento), que pueden ocultar partes del búfer o cambiar cómo se muestra, no son responsables.

Tardar una eternidad en completar un comando puede ser un bug, pero debe asegurarte de que es realmente culpa de Emacs. Algunos comandos simplemente tardan mucho. Teclee C-g (C-Break en MS-DOS) y luego C-h l para ver si la entrada que Emacs recibió era la que pretendía teclear; si la entrada era tal que sabe que debería haber sido procesada rápidamente, informa de un bug. Si no sabe si el comando debería tardar mucho, averígualo buscando en el manual o pidiendo ayuda.

Si un comando con el que está familiarizado causa un mensaje de error de Emacs en un caso en el que su definición habitual debería ser razonable, probablemente se trate de un bug.

Si un comando hace algo incorrecto, se trata de un error. Pero asegúrese de saber con certeza lo que debería haber hecho. Si no está familiarizado con el comando, puede que funcione correctamente. En caso de duda, lea la documentación del comando (consulte Ayuda por Comando o Nombre de Variable).

La definición prevista de un comando puede no ser la mejor definición posible para editar con ella. Esto es un tipo de problema muy importante, pero también es una cuestión de criterio. Además, es fácil llegar a esa conclusión por desconocimiento de algunas de las funciones existentes. Probablemente es mejor no quejarse de un problema de este tipo hasta que haya comprobado la documentación de la forma habitual, se sienta seguro de que la entiende y sepa con certeza que lo que quiere no está disponible. Pregunte también a otros Usuarios del Editor. Si no está seguro de lo que se supone hace el comando después de una lectura cuidadosa del manual, compruebe el índice y el glosario para cualquier término que pueda no estar claro.

Si después de releer cuidadosamente el manual sigue sin entender lo que el comando debería hacer, eso indica un error en el manual, que debería reportar. El trabajo del manual es dejarlo todo claro para la gente que no es experta en Emacs, incluido Usted. Es tan importante informar de los errores en la documentación como de los errores en el programa.

Si la documentación incorporada para una función o variable no concuerda con el manual, uno de los dos debe estar equivocado; eso es un bug.

Para problemas con paquetes que no son parte de Emacs, es mejor empezar informando a los desarrolladores del paquete.

53.3 Comprender la Notificación de Fallos

Cuando decide que hay un bug, es importante reportarlo, y reportarlo de una manera que sea útil. Lo más útil es una descripción exacta de los comandos que tecleas, empezando por el comando del shell para ejecutar Emacs, hasta que ocurre el problema, y los efectos producidos al teclear esos comandos.

El principio más importante a la hora de informar de un fallo es informar de los hechos. Las hipótesis y las descripciones verbales no sustituyen a los datos detallados en bruto. Informar de los hechos es sencillo, pero mucha gente se esfuerza en plantear explicaciones e informar de ellas en lugar de los hechos. Si las explicaciones se basan en suposiciones sobre cómo está implementado Emacs, no serán útiles; mientras tanto, a falta de los hechos, no tendremos información real sobre el fallo. Si quiere depurar realmente el problema y dar explicaciones que sean algo más que suposiciones, es útil, pero por favor, incluya también los hechos en bruto.

Por ejemplo, supongamos que teclea C-x C-f /glorp/baz.ugh RET, visitando un archivo que (ya sabe) resulta ser bastante grande, y Emacs muestra “Hoy me siento guapa”. El informe de error tendría que proporcionar toda esa información. No debería suponer que el problema se debe al tamaño del archivo y decir: «He visitado un archivo grande, y Emacs muestra “Hoy me siento guapa”». Esto es lo que entendemos por «adivinar explicaciones». El problema podría deberse a que hay una “z” en el nombre del archivo. Si es así, cuando recibimos su informe, probamos el problema con algún archivo grande, probablemente sin “z” en su nombre, y no vimos ningún problema. De ninguna manera podríamos adivinar que deberíamos intentar visitar un archivo con una “z” en su nombre.

Ni siquiera se debería decir «visitar un archivo» en lugar de C-x C-f. Eso es porque un archivo puede ser visitado de más de una manera, y no hay certeza de que todas ellas reproduzcan el problema. Del mismo modo, en lugar de decir «si tengo tres caracteres en la línea», diga «después de teclear RET A B C RET C-p», si ésa es la forma en que introdujo el texto; es decir, háblenos del texto que en su caso produjo el problema.

Si es posible, intenta reproducir rápidamente el fallo invocando Emacs con emacs -Q (para que Emacs arranque sin personalizaciones iniciales; ver Opciones Iniciales), y repitiendo los pasos que siguió para provocar el fallo. Si puede reproducir el fallo de esta forma, esto descarta fallos en tus personalizaciones y hace que el fallo sea mucho más fácil de reproducir. Entonces, tu informe de fallo debería comenzar indicando que inició Emacs con emacs -Q, seguido de la secuencia exacta de pasos para reproducir el fallo. Si es posible, infórmenos del contenido exacto de cualquier archivo necesario para reproducir el fallo.

Algunos fallos no son reproducibles desde emacs -Q; algunos no son fácilmente reproducibles en absoluto. En ese caso, debería informar de lo que tiene, pero, como antes, por favor, ciñalo a los hechos en bruto sobre lo que hizo para desencadenar el fallo la primera vez.

Si tiene varios problemas de los que quiera informar, haga un informe de error distinto para cada uno.

53.4 Lista de Comprobación para los Informes de Errores

Antes de reportar un fallo, primero intente ver si el problema ya ha sido reportado (ver Leyendo Informes de Fallos Existentes y Problemas Conocidos).

Si puede, pruebe la última versión de Emacs para ver si el problema ya ha sido solucionado. Mejor aún es probar la última versión de desarrollo. Reconocemos que esto no es fácil para algunas personas, así que no sienta que es absolutamente necesario hacerlo antes de hacer un informe.

La mejor manera de escribir un informe de error para Emacs es usar el comando M-x report-emacs-bug. Esto configura un búfer de correo (ver Enviar Correo) e inserta automáticamente parte de la información esencial. Sin embargo, no puede suministrar toda la información necesaria; aún así, debería leer y seguir las directrices que aparecen a continuación, para poder introducir a mano el resto de información crucial antes de enviar el mensaje. Puede que piense que parte de la información insertada por M-x report-emacs-bug no es relevante, pero a menos que esté absolutamente seguro, es mejor dejarla, para que los desarrolladores puedan decidir por sí mismos.

Cuando haya terminado de escribir su informe, teclee C-c C-c y será enviado a los mantenedores de Emacs en bug-gnu-emacs. Si no puede enviar correo desde Emacs, puede copiar el texto de su informe a su cliente de correo normal (si su sistema lo soporta, puede teclear C-c M-i para que Emacs lo haga por Ud.) y enviarlo a esa dirección. O simplemente puede enviar un correo electrónico a esa dirección describiendo el problema, incluyendo la información necesaria que se menciona a continuación.

Si quiere enviar código a Emacs (para arreglar un problema o implementar una nueva característica), la forma más fácil de hacerlo es enviar un parche al issue tracker de Emacs. Usa el comando M-x submit-emacs-patch para ello, que funciona de forma muy parecida a cuando reportas bugs; ver Enviando Parches para GNU Emacs.

En cualquier caso, su informe será enviado a la lista de correo “bug-gnu-emacs”, y almacenado en el GNU Bug Tracker en https://debbugs.gnu.org. Por favor, incluya una dirección de correo electrónico de respuesta válida, en caso de que necesitemos pedirle más información sobre su informe. Los envíos son moderados, por lo que puede haber un retraso antes de que su informe aparezca realmente en el rastreador.

No necesita saber cómo funciona el rastreador de errores de GNU para informar de un error, pero si lo desea, puede leer la documentación en línea del rastreador para ver las diversas características que puede utilizar.

Todo el correo enviado a la lista de correo “bug-gnu-emacs” se envía también al grupo de noticias “gnu.emacs.bug”. Lo contrario también es cierto, pero le pedimos que no envíe informes de errores (o respuestas) a través del grupo de noticias. Puede hacer mucho más difícil contactar con Usted si necesitamos pedirle más información, y no se integra bien con el rastreador de fallos.

Si sus datos superan los 500.000 bytes, por favor, no los incluya directamente en el informe de fallo; en su lugar, ofrézcase a enviarlos si se los pedimos, o póngalos a disposición en línea y diga dónde. Los archivos adjuntos grandes es mejor enviarlos comprimidos.

El Rastreador de fallos de GNU asignará un número de fallo a su informe; por favor, utilícelo en las siguientes discusiones, manteniendo la dirección del fallo en la lista de destinatarios, para que la discusión del fallo sea registrada por el rastreador. La dirección del fallo será como “nnnnn@debbugs.gnu.org”, donde nnnnn es el número del fallo.

Para que los mantenedores puedan investigar un fallo, su informe debe incluir todas estas cosas:

Una descripción de qué comportamiento observa que cree que es incorrecto. Por ejemplo, «El proceso de Emacs recibe una señal fatal», o, «El texto resultante es el siguiente, que

creo que es incorrecto».

Por supuesto, si el fallo es que Emacs recibe una señal fatal, entonces no se puede pasar por alto. Pero si el fallo es un texto incorrecto, el mantenedor puede no darse cuenta de lo que está mal. ¿Por qué dejarlo al azar?

Incluso si el problema que experimenta es una señal fatal, debería decirlo explícitamente. Supongamos que algo extraño está ocurriendo, como que su copia del código fuente está desincronizada, o que ha encontrado un error en la librería C de su sistema. (¡Esto ha pasado!) Su copia puede fallar y la copia de aquí puede que no. Si dice que esperemos un fallo, entonces cuando Emacs aquí no se bloquee, sabremos que el fallo no está ocurriendo. Si no dice que esperemos un fallo, entonces no sabríamos si el fallo está ocurriendo, no podríamos sacar ninguna conclusión de nuestras observaciones.

Normalmente, la descripción del comportamiento y de la forma de reproducir el problema necesita especificar uno o más de los siguientes aspectos:

El texto completo de los archivos necesarios para reproducir el fallo.

Si puede decirnos una forma de causar el problema sin visitar ningún archivo, por favor hágalo. Esto facilita mucho la depuración. Si necesita archivos, asegúrese de que podemos ver su contenido exacto. Por ejemplo, puede importar si hay espacios al final de las líneas, o una nueva línea después de la última línea en el buffer (nada debería importar si la última línea está terminada, pero intente decírselo a los bugs).

Los comandos precisos que necesitamos teclear para reproducir el fallo. Si es posible, da una receta completa para un Emacs iniciado con la opción “-Q” (ver Opciones iniciales).

Esto evita sus personalizaciones.

Una forma de registrar con precisión la entrada a Emacs es escribir un archivo de regateo. Para iniciar a dicho archivo, use el comando M-x open-dribble-file. A partir de ese momento, Emacs copiará todas sus entradas en el fichero dribble especificado hasta que el proceso Emacs se cierre. Tenga en cuenta que información sensible (como contraseñas) puede acabar registrada en el archivo dribble.

Si el fallo es que el Manual de Emacs o el Manual de Referencia de Emacs Lisp no describen el comportamiento real de Emacs, o que el texto es confuso, copia el texto del manual

que cree que es el culpable. Si la sección es pequeña, basta con el nombre de la sección.

Si la manifestación del fallo es un mensaje de error de Emacs, es importante informar del texto exacto del mensaje de error, y un backtrace que muestre cómo el programa Lisp en Emacs llegó al error.

Para obtener el texto exacto del mensaje de error, cópielo del buffer Messages en el informe de fallo. Cópielo todo, no sólo una parte.

Compruebe si algún programa que haya cargado en el mundo Lisp, incluyendo su archivo de inicialización, establece alguna variable que pueda afectar al funcionamiento de Emacs.

Además, compruebe si el problema se produce en un Emacs recién iniciado sin cargar su fichero de inicialización (inicie Emacs con el modificador -Q para evitar que se carguen los ficheros init). Si el problema aún no se produce, debe informar del contenido preciso de cualquier programa que deba cargar en el mundo Lisp para que se produzca el problema.

Si el problema depende de un archivo de inicio o de otros programas Lisp que no forman parte del sistema Emacs estándar, debe asegurarte de que no se trata de un bug en esos

programas quejándose primero a sus mantenedores. Después de que verifiquen que están usando Emacs de una forma que se supone que funciona, deberían informar del fallo.

Si desea mencionar algo en el código fuente de GNU Emacs, muestra la línea de código con unas pocas líneas de contexto. No se limite a dar un número de línea. Los números de

línea en los fuentes de desarrollo no coinciden con los de tus fuentes. Llevaría trabajo extra a los mantenedores determinar qué código hay en tu versión en un número de línea dado, y no podríamos estar seguros.

Para posibles errores de visualización en terminales en modo texto, el tipo de terminal (el valor de la variable de entorno TERM), la entrada termcap completa para el terminal

desde /etc/termcap (ya que ese archivo no es idéntico en todas las máquinas), y la salida que Emacs envió realmente al terminal.

La forma de recoger la salida del terminal es invocar el comando M-x open-termscript justo después de iniciar Emacs; le pedirá el nombre del archivo donde registrar toda la salida del terminal hasta que el proceso Emacs se cierre. Si el problema se produce al arrancar Emacs, ponga la expresión Lisp

(open-termscript «~/termscript»)

en su fichero de inicialización de Emacs para que el fichero termscript esté abierto cuando Emacs muestre la pantalla por primera vez.

Atención: a menudo es difícil, y a veces imposible, arreglar un fallo dependiente del terminal sin acceso a un terminal del tipo que estimula el fallo.

El número de versión de Emacs. Sin esto, no sabremos si tiene sentido buscar el fallo en la versión actual de GNU Emacs.

M-x report-emacs-bug incluye esta información automáticamente, pero si no está usando ese comando para su informe puede obtener el número de versión escribiendo M-x emacs-version RET. Si ese comando no funciona, probablemente tenga algo más que GNU Emacs, así que tendrá que informar del error en otro sitio.

Los argumentos de línea de comandos dados al comando configure cuando Emacs fue construido (incluidos automáticamente por M-x report-emacs-bug).

Una lista completa de cualquier modificación que haya hecho en el código fuente de Emacs. (Puede que no tengamos tiempo de investigar el fallo a menos que ocurra en un Emacs sin

modificar. Pero si ha hecho modificaciones y no nos lo dice, nos está enviando a una búsqueda inútil).

Sea preciso sobre estos cambios. Una descripción en inglés no es suficiente-envía un diff de contexto unificado para ellos.

Añadir archivos propios, o portarlo a otra máquina, es una modificación del código fuente.

Detalles de cualquier otra desviación del procedimiento estándar para instalar GNU Emacs.

Si el texto no ASCII o la internacionalización es relevante, la configuración regional que estaba vigente cuando arrancó Emacs. Esto es incluido automáticamente por M-x

report-emacs-bug; alternativamente, en GNU/Linux y sistemas Unix, o si usa un shell estilo POSIX como Bash, puede usar este comando del shell para ver los valores relevantes:

echo LC_ALL=$LC_ALL LC_COLLATE=$LC_COLLATE LC_CTYPE=$LC_CTYPE
LC_MESSAGES=$LC_MESSAGES LC_TIME=$LC_TIME LANG=$LANG

También puede utilizar el comando locale, si su sistema lo tiene, para mostrar su configuración regional.

Estas son algunas cosas que no son necesarias en un informe de error:

Una descripción de la envoltura del fallo-esto no es necesario para un fallo reproducible.

A menudo, la gente que encuentra un fallo pasa mucho tiempo investigando qué cambios en el archivo de entrada harán que el fallo desaparezca y qué cambios no lo afectarán.

Esto suele llevar mucho tiempo y no es muy útil, porque la forma en que encontraremos el fallo es ejecutando un único ejemplo bajo el depurador con puntos de interrupción, no por pura deducción de una serie de ejemplos. Es mejor ahorrar tiempo no buscando ejemplos adicionales. Es mejor enviar el informe de error de inmediato, volver a la edición, y encontrar otro error del que informar.

Por supuesto, si puede encontrar un ejemplo más simple para informar en lugar del original, eso es una conveniencia. Los errores en la salida serán más fáciles de detectar, ejecutar bajo el depurador llevará menos tiempo, etc.

Sin embargo, la simplificación no es vital; si no puedes hacerlo o no tienes tiempo para intentarlo, por favor, informa del fallo con tu caso de prueba original.

Un archivo de volcado del núcleo.

Depurar el volcado del núcleo puede ser útil, pero sólo puede hacerse en su máquina, con su ejecutable de Emacs. Por lo tanto, enviar el archivo de volcado del núcleo a los mantenedores de Emacs no será útil. Sobre todo, ¡no incluyas el archivo del núcleo en un informe de error por correo electrónico! Un mensaje tan grande puede ser extremadamente inconveniente.

Una traza de llamada al sistema de la ejecución de Emacs.

Las trazas de llamadas al sistema son muy útiles para ciertos tipos especiales de depuración, pero en la mayoría de los casos dan poca información útil. Por eso es extraño que mucha gente piense que la forma de dar información sobre un fallo es enviar un rastreo de llamada al sistema. Tal vez se trate de un hábito formado a partir de la experiencia depurando programas que no tienen código fuente ni símbolos de depuración.

En la mayoría de los programas, un backtrace es normalmente mucho, mucho más informativo que un system-call trace. Incluso en Emacs, un simple backtrace es generalmente más informativo, aunque para dar una información completa debería complementar el backtrace mostrando los valores de las variables e imprimiéndolos como objetos Lisp con pr (ver más arriba).

Un parche para el fallo.

Un parche para el fallo es útil si es bueno. Pero no omita el resto de la información que necesita un informe de fallo, como el caso de prueba, suponiendo que un parche es suficiente. Puede que veamos problemas con tu parche y decidamos solucionar el problema de otra manera, o puede que no lo entendamos en absoluto. Y si no podemos entender qué fallo está intentando arreglar, o por qué su parche debería ser una mejora, no debemos instalarlo. Vea Envío de Parches para GNU Emacs, para directrices sobre cómo facilitarnos la comprensión e instalación de sus parches.

Una suposición sobre cuál es el fallo o de qué depende.

Estas suposiciones suelen ser erróneas. Incluso los expertos no pueden acertar sobre tales cosas sin usar primero el depurador para encontrar los hechos.

Si está dispuesto a depurar Emacs y proporcionar información adicional sobre el bug, aquí tiene algunos consejos útiles:

Si el fallo se manifiesta como un mensaje de error, intenta proporcionar un backtrace de Lisp para el error. Para hacer un backtrace para el error, usa M-x toggle-debug-on-error

antes de que ocurra el error (es decir, debe dar ese comando y luego hacer que ocurra el error). Esto hace que el error inicie el depurador de Lisp, que le muestra un backtrace. Copie el texto del backtrace del depurador en el informe de error. (El backtrace es más detallado si carga los archivos fuente *.el de Lisp relevantes antes de desencadenar el error, así que hágalo si sabe cómo encontrar y cargar esos archivos).

Para depurar el error, le sugerimos que utilice Edebug. Vea Edebug en el Manual de Referencia de Emacs Lisp, para información sobre depuración de programas Emacs Lisp con el paquete Edebug.

Este uso del depurador sólo es posible si sabe cómo hacer que el error vuelva a ocurrir. Si no puede hacer que vuelva a suceder, al menos copia el mensaje de error completo.

Si Emacs parece estar atascado en un bucle infinito o en una operación muy larga, tecleando C-g con la variable debug-on-quit no nil arrancará el depurador Lisp y mostrará un

backtrace. Este backtrace es útil para depurar bucles tan largos, así que si puede producirlo, cópielo en el informe de error.

Si no puede hacer que Emacs responda a C-g (por ejemplo, porque inhibit-quit está activado), puede intentar enviar la señal especificada por debug-on-event (por defecto SIGUSR2) desde fuera de Emacs para hacer que entre en el depurador.

La información adicional de un depurador de C como GDB podría permitir a alguien encontrar un problema en una máquina de la que no dispone. Si no sabe cómo usar GDB, por favor lea el

manual de GDB-no es muy largo, y usar GDB es fácil. Puede encontrar la distribución de GDB, incluyendo el manual de GDB en formato online, en la mayoría de los mismos lugares donde es posible encontrar la distribución de Emacs. Para ejecutar Emacs bajo GDB, debe cambiar al subdirectorio src en el que se compiló Emacs, y luego escribir gdb ./emacs. Es importante que el directorio src sea actual para que GDB lea el archivo .gdbinit en este directorio. (También puede decirle a GDB que lea ese archivo desde dentro de GDB, escribiendo source ./.gdbinit).

Sin embargo, necesita pensar cuando recoge la información adicional si quiere que muestre lo que causa el bug.

Por ejemplo, mucha gente envía sólo un backtrace a nivel de C, pero eso no es muy útil por sí mismo. Un simple backtrace con argumentos a menudo transmite poco sobre lo que está ocurriendo dentro de GNU Emacs, porque la mayoría de los argumentos listados en el backtrace son punteros a objetos Lisp. Los valores numéricos de estos punteros no tienen ningún significado; todo lo que importa es el contenido de los objetos a los que apuntan (y la mayoría de los contenidos son ellos mismos punteros).

Para proporcionar información útil, es necesario mostrar los valores de los objetos Lisp en notación Lisp. Haga esto para cada variable que sea un objeto Lisp, en varios marcos de pila cerca de la parte inferior de la pila. Mire el código fuente para ver qué variables son objetos Lisp, porque el depurador piensa en ellas como enteros.

Para mostrar el valor de una variable en sintaxis Lisp, primero imprima su valor, luego use el comando pr de GDB definido por el usuario para imprimir el objeto Lisp en sintaxis Lisp. (Si debe utilizar otro depurador, llame a la función debug_print con el objeto como argumento). El comando pr se define en el archivo .gdbinit, y sólo funciona si está depurando un proceso en ejecución (no con un volcado del núcleo).

Para hacer que los errores de Lisp detengan Emacs y vuelvan a GDB, ponga un punto de interrupción en Fsignal.

Para obtener un backtrace de las funciones Lisp en ejecución, escriba el comando xbacktrace de GDB.

El archivo .gdbinit define otros comandos útiles para examinar los tipos de datos y el contenido de los objetos Lisp. Sus nombres comienzan por “x”. Estos comandos trabajan a un nivel más bajo que pr, y son menos convenientes, pero pueden funcionar incluso cuando pr no lo hace, como cuando se depura un volcado del núcleo o cuando Emacs ha tenido una señal fatal.

Consejos más detallados y otras técnicas útiles para depurar Emacs están disponibles en el fichero etc/DEBUG en la distribución de Emacs. Ese fichero también incluye instrucciones para investigar problemas por los que Emacs deja de responder (mucha gente asume que Emacs está «colgado», cuando en realidad podría estar en un bucle infinito).

Para encontrar el fichero etc/DEBUG en tu instalación de Emacs, usa el nombre del directorio almacenado en la variable data-directory.

53.5 Envío de parches para GNU Emacs

Si quiere escribir correcciones de errores o mejoras para GNU Emacs, es de gran ayuda. Cuando envíe sus cambios, por favor, siga estas directrices para facilitar su uso a los 4mantenedores. Si no sigue estas directrices, su información puede seguir siendo útil, pero usarla llevará un trabajo extra. Mantener GNU Emacs es mucho trabajo en el mejor de los casos, y no podemos mantenerlo a menos que Usted haga todo lo posible por ayudar.

Cada parche debe tener varias piezas de información antes de que podamos evaluarlo adecuadamente. Se describen a continuación.

Cuando tenga todas estas piezas, utilice el comando M-x submit-emacs-patch para enviar el parche. El comando le pedirá el Asunto del parche y un archivo de parche. A continuación, creará y mostrará un búfer en modo Mensaje con el archivo del parche como adjunto, mostrará el búfer y le permitirá explicar más sobre el parche y añadir cualquier otra información que se solicite a continuación. Cuando haya terminado, escriba C-c C-c para enviar el parche por correo electrónico a los desarrolladores. Será enviado al GNU Bug Tracker en https://debbugs.gnu.org. El rastreador asignará un número a su envío, al igual que hace con los informes de errores. Los desarrolladores normalmente responderán, quizás pidiéndole más detalles o cualquier información adicional, así que asegúrese de incluir una dirección de correo electrónico de respuesta válida.

Esto es lo que le pedimos que proporcione como parte de sus envíos de parches:

Una explicación de qué problema está solucionando o qué mejora aportarán los parches:

Para corregir un error existente, es mejor responder a la discusión relevante en la lista “bug-gnu-emacs”, o a la entrada del error en el GNU Bug Tracker en

https://debbugs.gnu.org. Explique por qué su cambio soluciona el error.

Para una nueva característica, incluya una descripción de la característica y su implementación.

Para un nuevo fallo, incluya un informe de fallo apropiado para el problema que cree que ha solucionado; vea Lista de Comprobación para Informes de Fallos. Tenemos que

convencernos de que el cambio es correcto antes de instalarlo. Incluso si es correcto, podríamos tener problemas para entenderlo si no tenemos una forma de reproducir el problema que intenta solucionar.

Incluya en sus cambios de código todos los comentarios que sean apropiados para ayudar a las Personas que lean el código fuente en el futuro a entender por qué era necesario ese

cambio.

No mezcle cambios realizados por motivos diferentes. Envíelos por separado.

Si realiza dos cambios por motivos distintos, es posible que no queramos instalar ambos. Podríamos querer instalar sólo uno, o instalar cada uno en una versión diferente de Emacs.

Si los envía todos mezclados en un único conjunto de diffs, tenemos que hacer un trabajo extra para separarlos, para averiguar qué partes del cambio sirven a qué propósito. Si no tenemos tiempo para esto, puede que tengamos que posponer la inclusión de sus parches durante mucho tiempo.

Si envía cada cambio tan pronto como lo haya escrito, con su propia explicación, entonces dos cambios nunca se enredan, y podemos considerar cada uno adecuadamente sin ningún

trabajo extra para desenredarlos.

Envíe cada cambio tan pronto como haya terminado. A veces la gente cree que nos está ayudando acumulando muchos cambios para enviarlos todos juntos. Como ya se ha explicado, esto

es absolutamente lo peor que puedes hacer.

Ya que debe enviar cada cambio por separado, es mejor que lo haga enseguida. Eso nos da la opción de instalarlo inmediatamente si es importante.

El propio parche. Puede producirse de una de las siguientes maneras:

Si está usando el repositorio de Emacs, asegúrate de que su copia está actualizada (por ejemplo, con git pull). Puede confirmar sus cambios en una rama privada y generar un

parche a partir de la versión maestra usando git format-patch master. (Este es el método preferido, ya que nos facilita el trabajo de aplicar el parche). O puede dejar sus cambios sin confirmar y usar git diff, como se describe a continuación.

Use diff -u para hacer sus diferencias. Si tiene GNU diff, usa diff -u -F”^[_a-zA-Z0-9$]+ *(” cuando haga diffs de código C. Esto muestra el nombre de la función que está

siendo modificada. Esto muestra el nombre de la función en la que se produce cada cambio.

Cuando produzca los diffs, evite cualquier ambigüedad sobre cuál es la versión antigua y cuál es la nueva. Por favor, haga que la versión antigua sea el primer argumento del diff, y la nueva versión el segundo argumento. Y por favor, de a una versión u otra un nombre que indique si es la versión antigua o la nueva.

Escriba las entradas de registro de sus cambios. Esto es tanto para ahorrarnos el trabajo extra de escribirlas, como para ayudarnos a explicar tus cambios para que podamos

entenderlos.

El propósito del registro de cambios es explicar la lógica de los cambios, la forma en que el código modificado resuelve los problemas que su parche está tratando de solucionar, y también mostrar a la gente dónde encontrar lo que se ha cambiado. Así que tiene que ser específico sobre qué funciones has cambiado y por qué. Para más detalles sobre nuestro estilo y requisitos para un buen mensaje de confirmación, por favor vea la sección «Mensajes de confirmación» del archivo CONTRIBUTE en el árbol de fuentes de Emacs.

Por favor, mire también las entradas del registro de confirmaciones recientes para ver qué tipo de información poner, y para aprender el estilo que usamos. Tenga en cuenta que, a diferencia de otros proyectos, requerimos registros de cambios para la documentación, es decir, archivos Texinfo. Vea Change Logs, vea https://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html, Vea Conceptos del Registrod de Cambios en GNU Coding Standards.

Cuando escriba la corrección, tenga en cuenta que no podemos instalar un cambio que rompería otros sistemas. Por favor, piense qué efecto tendrá su cambio si se compila y/o utiliza

en otro tipo de sistema.

A veces la gente envía correcciones que podrían ser una mejora en general, pero es difícil estar seguro de ello. Es difícil instalar esos cambios porque tenemos que estudiarlos con mucho cuidado. Por supuesto, una buena explicación del razonamiento por el que llegó a la conclusión de que el cambio era correcto puede ayudar a convencernos.

Los cambios más seguros son los cambios en los archivos o partes de los archivos que sólo se utilizan para una máquina en particular o un sistema en particular. Estos son seguros porque no pueden crear nuevos errores en otras máquinas o sistemas.

Por favor, ayúdenos a mantener el ritmo de trabajo diseñando el parche de forma que sea claramente seguro de instalar.

Anterior Siguiente

Compilado con Sphinx usando un tema proporcionado por Read the Docs.

</html>

53 KiB Raw Blame History