Jak debugować awarię emacsa?

Debuguję, dlaczego emacs ulega awarii podczas używania funkcji z pakietu ¹ . Celem tego procesu debugowania jest uzyskanie użytecznych danych do przesłania M-x report-emacs-bug.

Aby uzyskać pomoc na temat debugowania awarii emacsa, przejrzałem już Podręcznik Emacsa - Awarie i Podręcznik Emacsa - Po awarii , ale one nie pomogły.

Podręcznik After A Crash odnosi się do, emacs-buffer.gdbale nie mam pojęcia, jak go używać. Pytając google o pomoc, natknąłem się na to pytanie emacs.SE i ponownie skompilowałem emacsa używając -ggdb3flag.

Nie mam wcześniejszego doświadczenia z używaniem, gdbwięc próbowałem kilku nieudanych prób użycia emacs-buffer.gbdpliku.

Oto, co próbowałem:

• 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

Na marginesie, -ggdb3załadowanie emacsa skompilowanego z flagą zajmuje około 10 sekund dłużej; wcześniej było to 5-6 sekund, teraz około 16-17 sekund. Znam dokładne sekundy z powodu kodu, który oblicza to w moim init. Czy spodziewany jest wzrost czasu uruchamiania?

_{Przypis 1: emacs stale się zawiesza, gdy undo-treepróbuje przywrócić historię cofania dla określonego pliku .org (którego nie mogę udostępnić publicznie). Mam (setq undo-tree-auto-save-history t). Ta awaria zdarza się tylko na emacs git master, a nie na emacs 24.5. W undo-treesystemie emacs 24.5 zgłasza błąd informujący, że nie można załadować historii cofania (nawet za pośrednictwem pliku historii cofnięć), ale przynajmniej sesja emacs nie ulega awarii w tej wersji.}

Najłatwiejszym sposobem debugowania awarii Emacsa jest uruchomienie Emacsa pod gdb, a następnie zrobienie czegokolwiek, co odtworzy awarię.

Zakładając, że budujesz Emacsa ze źródła, powinieneś przejść CFLAGS="-O0 -g3"do ./configureskryptu. To powoduje, że kompilator C wyłącza optymalizacje (co może wprowadzać zamieszanie podczas debugowania) i aktywuje maksymalne informacje debugowania w pliku wykonywalnym. Uruchom, makeaby zbudować Emacsa.

Następnie zacznij gdbod srckatalogu z drzewa Emacsa:

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

W OSX będziesz chciał przejść --with-nsdo ./configureskryptu i uruchomić gdb na Emacsie wewnątrz utworzonej aplikacji:

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

Powodem do uruchomienia z srckatalogu jest to, że istnieje .gdbinitplik, który konfiguruje przydatne definicje funkcji GDB do debugowania Emacsa. Jeśli ten plik został załadowany, powinieneś zobaczyć coś takiego podczas uruchamiania 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.

Wpisz, raby uruchomić Emacsa. Możesz przekazać dodatkowe argumenty w tym samym wierszu, np r --debug-init.

Następnie spróbuj spowodować awarię Emacsa. Jeśli się zawiesi, powinieneś zobaczyć notatkę na ten temat gdb, a (gdb)ponownie pojawi się monit. Jeśli Emacs się nie zawiesi, ale zawiesi, możesz nacisnąć C-zterminal, w którym biegniesz, gdbaby wrócić do monitu.

Po wyświetleniu monitu wpisz, btaby uzyskać ślad. Jako bonus, jeśli .gdbinitplik Emacsa został poprawnie załadowany, po śladzie C zobaczysz ślad Lisp. Oba ślady są bardzo przydatnymi rzeczami do włączenia M-x report-emacs-bug.

W etc/DEBUGpliku w drzewie Emacsa znajduje się znacznie więcej informacji, w tym jak sprawdzić stan zmiennych itp . Możesz go otworzyć, wpisując C-h C-dwewnątrz Emacsa, lub możesz przeczytać go online .