Comment déboguer un plantage emacs?

Je débogue pourquoi emacs se bloque lors de l'utilisation d'une fonction à partir d'un package ¹ . Le but de ce processus de débogage est d'obtenir des données utiles à soumettre en utilisant M-x report-emacs-bug.

Pour obtenir de l'aide sur la façon de déboguer les plantages d'emacs, j'ai déjà regardé Emacs Manual - Crashing et Emacs Manual - After a Crash , mais ils n'ont pas aidé.

Le manuel After A Crash fait référence emacs-buffer.gdbmais je ne sais pas comment l'utiliser. En demandant de l'aide à Google, je suis tombé sur cette question emacs.SE et j'ai recompilé emacs en utilisant les -ggdb3drapeaux.

Je n'ai aucune expérience préalable de l'utilisation gdbet j'ai donc tenté quelques tentatives infructueuses d'utilisation du emacs-buffer.gbdfichier.

Voici ce que j'ai essayé:

• 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

Sur une note latérale, emacs compilé avec le -ggdb3drapeau prend environ 10 secondes de plus à charger; plus tôt, c'était 5-6 secondes, maintenant environ 16-17 secondes. Je connais les secondes exactes à cause d'un code qui calcule cela dans mon init. Cette augmentation du temps de démarrage est-elle attendue?

_{Note de bas de page 1: emacs se bloque systématiquement lors d'une undo-treetentative de restauration de l'historique d'annulation d'un fichier .org particulier (que je ne peux pas partager publiquement). Je l'ai (setq undo-tree-auto-save-history t). Ce plantage ne se produit que sur emacs git master, pas sur emacs 24.5. Sur emacs 24.5, undo-treegénère une erreur indiquant qu'il est impossible de charger l'historique d'annulation (même si le fichier historique d'annulation existe), mais au moins la session emacs ne se bloque pas sur cette version.}

La façon la plus simple de déboguer un crash Emacs est de démarrer Emacs sous gdb, puis de faire tout ce qui reproduit le crash.

En supposant que vous construisez vos Emacs à partir des sources, vous devez passer CFLAGS="-O0 -g3"au ./configurescript. Cela fait que le compilateur C désactive les optimisations (ce qui peut rendre les choses confuses lors du débogage) et active le maximum d'informations de débogage dans l'exécutable. Courez makepour construire Emacs.

Ensuite, démarrez à gdbpartir du srcrépertoire de votre arborescence Emacs:

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

Sur OSX, vous voudrez passer --with-nsau ./configurescript et démarrer gdb sur Emacs à l'intérieur de l'application créée:

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

La raison de commencer à partir du srcrépertoire est qu'il existe un .gdbinitfichier qui définit des définitions de fonction GDB utiles pour le débogage d'Emacs. Si ce fichier a été chargé, vous devriez voir quelque chose comme ça au démarrage 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.

Tapez rpour démarrer Emacs. Vous pouvez passer des arguments supplémentaires sur la même ligne, par exemple r --debug-init.

Essayez ensuite de faire planter Emacs. S'il se bloque, vous devriez voir une note à ce sujet gdbet vous serez de nouveau laissé à l' (gdb)invite. Si Emacs ne plante pas, mais se bloque, vous pouvez frapper C-zdans le terminal où vous exécutez gdbpour revenir à l'invite.

Une fois à l'invite, tapez btpour obtenir une trace. En prime, si le .gdbinitfichier Emacs a été correctement chargé, vous verrez une trace Lisp après la trace C. Les deux backtraces sont des éléments très utiles à inclure M-x report-emacs-bug.

Il y a beaucoup plus d'informations, y compris comment examiner l'état des variables, etc., dans le etc/DEBUGfichier de l'arborescence Emacs. Vous pouvez l'ouvrir en tapant C-h C-ddans Emacs, ou vous pouvez le lire en ligne .