Come posso eseguire il debug di un arresto anomalo di emacs?

Sto eseguendo il debug del motivo per cui emacs si arresta in modo anomalo quando si utilizza una funzione da un pacchetto ¹ . Lo scopo di questo processo di debug è ottenere dati utili da inviare utilizzando M-x report-emacs-bug.

Per ottenere assistenza su come eseguire il debug degli arresti anomali di emacs, ho già esaminato il manuale Emacs - Crashing and Emacs Manual - After a Crash , ma non mi hanno aiutato.

Il manuale di After A Crash fa riferimento emacs-buffer.gdbma non ho idea di come usarlo. Mentre chiedevo aiuto a google, mi sono imbattuto in questa domanda emacs.SE e ho ricompilato emacs usando le -ggdb3bandiere.

Non ho alcuna esperienza precedente nell'uso gdbe quindi ho provato alcuni tentativi falliti di utilizzare il emacs-buffer.gbdfile.

Ecco cosa ho provato:

• gdb -x /path/to/emacs-buffer.gdb
• gdb -> file /path/to/emacs-buffer.gdb
• gdb -> source /path/to/emacs-buffer.gdb
• source /path/to/emacs-buffer.gdb

Su una nota a margine, gli emacs compilati con il -ggdb3flag impiegano circa 10 secondi in più per caricarsi; prima erano 5-6 secondi, ora circa 16-17 secondi. Conosco i secondi esatti a causa di un codice che calcola quello nel mio init. Si prevede un aumento del tempo di avvio?

_{Nota 1: emacs si arresta in modo anomalo in modo coerente quando undo-treetenta di ripristinare la cronologia degli annullamenti per un determinato file .org (che non posso condividere pubblicamente). Io ho (setq undo-tree-auto-save-history t). Questo crash si verifica solo su emacs git master, non su emacs 24.5. Su emacs 24.5, undo-treegenera un errore che indica che non è in grado di caricare la cronologia degli annullamenti (anche se esiste il file della cronologia degli annullamenti), ma almeno la sessione di emacs non si arresta in modo anomalo su quella versione.}

Il modo più semplice per eseguire il debug di un arresto anomalo di Emacs è avviare Emacs gdb, quindi fare qualsiasi cosa riproduca l'incidente.

Supponendo che stai costruendo i tuoi Emacs dalla fonte, dovresti passare CFLAGS="-O0 -g3"alla ./configuresceneggiatura. Questo fa sì che il compilatore C disattivi le ottimizzazioni (che possono creare confusione durante il debug) e attiva le informazioni di debug massime nell'eseguibile. Corri makeper costruire Emacs.

Quindi, inizia gdbdalla srcdirectory del tuo albero Emacs:

$ cd ~/my-emacs-tree/src
$ gdb ./emacs

Su OSX, ti consigliamo di passare --with-nsallo ./configurescript e avviare gdb su Emacs all'interno dell'applicazione creata:

$ cd ~/my-emacs-tree
$ make install
$ cd src
$ gdb nextstep/Emacs.app/Contents/MacOS/Emacs

Il motivo per iniziare dalla srcdirectory è che esiste un .gdbinitfile che imposta utili definizioni delle funzioni GDB per il debug di Emacs. Se quel file è stato caricato, dovresti vedere qualcosa del genere all'avvio gdb:

DISPLAY = /private/tmp/com.apple.launchd.cNjhIdtUNd/org.macosforge.xquartz:0
TERM = xterm-256color
Breakpoint 1 at 0x1000ca444: file ../../src/emacs.c, line 353.
Breakpoint 2 at 0x1000e7e34: file ../../src/sysdep.c, line 926.

Digitare rper avviare Emacs. È possibile passare argomenti aggiuntivi sulla stessa riga, ad es r --debug-init.

Quindi prova a far arrestare Emacs. Se si arresta in modo anomalo, dovresti vedere una nota a riguardo gdbe verrai di (gdb)nuovo visualizzato al prompt. Se Emacs non si arresta in modo anomalo, ma si blocca, puoi premere C-znel terminale in cui stai correndo gdbper tornare al prompt.

Una volta richiesto, digitare btper ottenere una backtrace. Come bonus, se il .gdbinitfile Emacs è stato caricato correttamente, vedrai un backtrace di Lisp dopo il backtrace di C. Entrambe le tracce sono cose molto utili da includere M-x report-emacs-bug.

Ci sono molte più informazioni, incluso come esaminare lo stato delle variabili ecc., Nel etc/DEBUGfile nella struttura di Emacs. Puoi aprirlo digitando C-h C-dEmacs, oppure puoi leggerlo online .