Mejor depuración de estrellarse Emacs?

Aunque Emacs (24.3.93.1) funciona bien si se inicia desde el Finder, si se inicia la versión del terminal:

/Applications/Emacs.app/Contents/MacOS/Emacs -nw

Emacs se bloquea con:

Fatal error 11: Segmentation fault[1] 51512 abort /Applications/Emacs.app/Contents/MacOS/Emacs -nw.

Parece que el problema es causado por una sola línea en init.el,

(set-face-attribute 'default nil :font "Menlo-16")

Si esa línea se comenta, la versión de terminal de Emacs también comenzará bien.

Identificar la causa del accidente me llevó varias horas (disminuyendo mi init.el mitad por mitad).

Soy consciente de que, en cualquier caso, Emacs heredará cualquier fuente y tamaño de fuente especificado en la aplicación de terminal (básicamente, esa línea no es significativa en el cli).

En términos generales, ¿hay una mejor manera de depurar un Emacs que falla? ¿Quizás utilizando algún tipo de depurador de cli que imprima un mensaje más descriptivo?
¿Por qué esa línea bloquea Emacs a través de cli, pero no si se inicia desde Finder?

— gsl
fuente

¿realmente se está lanzando desde el cli? o iniciar la versión del terminal que está causando el problema? ¿Intenta poner algún error en el set-face-attribute? (condition-case err (set-face-attribute ...) (error (mensaje "Whoops!")))

— nic ferrier

Presentar un informe de error. Emacs nunca debe bloquearse debido al código lisp. Pero esto puede ser un problema con la compilación específica que está utilizando, ¿es el lanzamiento oficial?

— Malabarba

@ nic-ferrier: ahora solo tengo una línea en init.el, (condition-case err (set-face-attribute 'default nil :font "Menlo-16") (error (message "Whoops!")))todavía tengo el mismo bloqueo con el mismo mensaje de error. No hay mensajes adicionales de origen de elisp.

— gsl

@ Malabarba: He tratado con GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.orgde emacsformacosx.com , y Emacs no se desplome. Por lo tanto, debe ser un error en versiones posteriores. Presentaré un informe de error.

— gsl

Como se indica @Malabarba: Informe un error (inmediatamente): M-x report-emacs-bug. Los desarrolladores de Emacs lo guiarán a través de lo que puede hacer para ayudar a depurar el problema.

— Dibujó el

Respuestas:

Para ayudarte a rastrearlo la próxima vez

Esto me sucedió antes. Hubo una situación en la que se string-to-intestrelló Emacs, y también me llevó horas identificarlo.
Lo siento, no puedo proporcionar una mejor respuesta, pero los bloqueos de Emacs ocurren en el fondo del código C, y no hay herramientas integradas disponibles para rastrear tales problemas.

Supongo que gdbes posible depurarlo, pero su efectividad dependerá de su competencia gdb.

Lo que realmente necesitas hacer es

Presentar un informe de error

Se supone que el código elisp puro (sin compilación de bytes) nunca bloquea Emacs. Podría provocar un bloqueo (debido a un bucle infinito) y podría hacer que Emacs se quede sin memoria. Pero, más allá de eso, cualquier accidente es un error .

M-x report-emacs-bug

Simplemente proporcionar este ejemplo de trabajo mínimo que se le ocurrió, junto con una descripción de su compilación y sistema, debería ser suficiente ayuda para los amables desarrolladores.

— Malabarba
fuente

Usar gdb sería la única forma. Podríamos agregar cosas a Emacs para envolver cada llamada de C en algo que se auto capturaría pero que estaría sobrecargado todo el tiempo. Se supone que Emacs no se bloquea, si lo hace, debemos manejar específicamente ese error para que ya no lo haga. Así que sí, si está roto, presenta un error. Use gdb por todos los medios para descubrir absolutamente dónde está el error.

— nic ferrier

Como referencia para depurar con gdb, querrá usar src / temacs del árbol de compilación. Este es Emacs sin el elisp pre-descargado que confunde al depurador.

gdb --args src/temacs -nw

— stsquad
fuente

Gracias, excelentes consejos (y no es fácil encontrarlos también). Gracias.

— gsl