Besseres Debuggen von abstürzenden Emacs?

Obwohl Emacs (24.3.93.1) beim Starten über den Finder einwandfrei funktioniert, wenn die Terminalversion gestartet wird:

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

Emacs stürzt ab mit:

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

Es scheint, dass das Problem durch eine einzelne Zeile in init.el verursacht wird.

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

Wenn diese Zeile auskommentiert ist, startet auch die Terminalversion von Emacs einwandfrei.

Um die Ursache des Absturzes zu lokalisieren, brauchte ich mehrere Stunden (um mein Init.el um die Hälfte zu verringern).

Mir ist bewusst, dass Emacs in jedem Fall die in der Terminal-App angegebene Schriftart und Schriftgröße erbt (im Grunde ist diese Zeile in der CLI nicht aussagekräftig).

Gibt es im Allgemeinen eine bessere Möglichkeit, einen abstürzenden Emacs zu debuggen? Vielleicht eine Art Cli-Debugger verwenden, der eine aussagekräftigere Nachricht druckt?
Warum stürzt diese Linie Emacs über CLI ab, aber nicht, wenn sie vom Finder aus gestartet wird?

— gsl
quelle

startet es wirklich von der cli? oder die Terminalversion starten, die das Problem verursacht? Versuchen Sie, das Set-Face-Attribut mit einem Fehler zu versehen? (Bedingung-Fall err (Set-Face-Attribut ...) (Fehler (Nachricht "Whoops!")))

— Nic Ferrier

Einen Fehlerbericht einreichen. Emacs sollten niemals aufgrund von Lisp-Code abstürzen. Dies kann jedoch ein Problem mit dem von Ihnen verwendeten Build sein. Ist es die offizielle Version?

— Malabarba

@ nic-ferrier: Ich habe jetzt nur eine Zeile in init.el, (condition-case err (set-face-attribute 'default nil :font "Menlo-16") (error (message "Whoops!")))trotzdem habe ich den gleichen Absturz mit der gleichen Fehlermeldung. Keine zusätzlichen Nachrichten mit Elisp-Ursprung.

— GSL

@ malabarba: Ich habe es mit GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.orgvon emacsformacosx.com versucht und Emacs stürzt nicht ab. Es muss also ein Fehler in späteren Versionen sein. Ich werde einen Fehlerbericht einreichen.

— GSL

Wie @Malabarba anzeigte: Einen Fehlerbericht einreichen (sofort) : M-x report-emacs-bug. Die Emacs-Entwickler führen Sie dann durch die Maßnahmen, die Sie zur Fehlerbehebung ergreifen können.

— Drew

Antworten:

Damit Sie es beim nächsten Mal nachverfolgen können

Das ist mir schon mal passiert. Es gab eine Situation, in string-to-intder Emacs abgestürzt war, und ich brauchte Stunden, um genau zu bestimmen.
Leider kann ich keine bessere Antwort geben, aber Emacs-Abstürze treten tief im C-Code auf, und es sind keine integrierten Tools verfügbar, um solche Probleme aufzuspüren.

Ich nehme an, dass das Debuggen mit gdbmöglich ist, aber seine Wirksamkeit hängt von Ihren Kenntnissen ab gdb.

Was Sie wirklich tun müssen, ist

Einen Fehlerbericht einreichen

Reiner Elisp-Code (nicht bytekompiliert) soll Emacs niemals zum Absturz bringen. Dies kann zu einem Stillstand führen (aufgrund einer Endlosschleife) und dazu führen, dass Emacs nicht mehr über genügend Speicher verfügt. Aber darüber hinaus ist jeder Absturz ein Fehler .

M-x report-emacs-bug

Die einfache Bereitstellung dieses minimal funktionierenden Beispiels zusammen mit einer Beschreibung Ihres Builds und Systems sollte für die freundlichen Entwickler ausreichend sein.

— Malabarba
quelle

Die Verwendung von GDB wäre der einzige Weg. Wir könnten Emacs etwas hinzufügen, um jeden C-Anruf in etwas zu verpacken, das sich selbst fängt, aber die ganze Zeit über Kopf ist. Emacs soll nicht abstürzen. Wenn dies der Fall ist, sollten wir diesen Fehler speziell behandeln, damit er nicht mehr auftritt. Also ja, wenn es kaputt ist, melde einen Fehler. Verwenden Sie gdb auf jeden Fall, um herauszufinden, wo der Fehler liegt.

— Nic Ferrier

Als Referenz für das Debuggen mit gdb möchten Sie src / temacs aus dem Build-Baum verwenden. Dies ist Emacs ohne das vorab ausgegebene Elisp, das den Debugger verwirrt.

gdb --args src/temacs -nw

— stsquad
quelle

Vielen Dank, exzellente Ratschläge (und auch nicht leicht zu finden). Vielen Dank.

— gsl