Lebih baik men-debug Emacs yang mogok?

Meskipun Emacs (24.3.93.1) berjalan dengan baik jika diluncurkan dari Finder, jika versi terminal diluncurkan:

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

Emacs mogok dengan:

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

Tampaknya masalah ini disebabkan oleh satu baris di init.el,

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

Jika baris itu dikomentari, versi terminal Emacs akan mulai baik juga.

Untuk mengetahui penyebab kecelakaan itu memakan waktu beberapa jam (mengurangi setengah init.el saya setengah).

Saya sadar bahwa bagaimanapun Emacs akan mewarisi font dan ukuran font apa pun yang ditentukan dalam aplikasi terminal (pada dasarnya, baris itu tidak berarti dalam cli.)

Secara umum, apakah ada cara yang lebih baik untuk men-debug Emacs yang mogok? Mungkin menggunakan semacam cli debugger yang akan mencetak pesan yang lebih deskriptif?
Mengapa garis itu menabrak Emacs via cli, tetapi tidak jika diluncurkan dari Finder?

— gsl
sumber

apakah ini benar-benar diluncurkan dari cli? atau meluncurkan versi terminal yang menyebabkan masalah? Coba letakkan beberapa kesalahan pada atribut set-face-atribut? (condition-case err (set-face-atribut ...) (error (pesan "Whoops!")))

— nic ferrier

Ajukan laporan bug. Emacs seharusnya tidak pernah crash karena kode lisp. Tapi ini mungkin masalah dengan bangunan spesifik yang Anda gunakan, apakah ini rilis resmi?

— Malabarba

@ nic-ferrier: Saya sekarang hanya memiliki satu baris di init.el, (condition-case err (set-face-attribute 'default nil :font "Menlo-16") (error (message "Whoops!")))masih ada crash yang sama dengan pesan kesalahan yang sama. Tidak ada pesan tambahan yang berasal dari elisp tambahan.

— gsl

@ malabarba: Saya sudah mencoba dengan GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.orgdari emacsformacosx.com , dan Emacs tidak macet. Jadi, itu pasti bug di versi yang lebih baru. Saya akan mengajukan laporan bug.

— gsl

Sebagai @Malabarba ditunjukkan: Berkas laporan bug (segera): M-x report-emacs-bug. Pengembang Emacs kemudian akan membimbing Anda melalui apa yang dapat Anda lakukan untuk membantu men-debug masalah.

— Drew

Jawaban:

Untuk membantu Anda melacaknya lain kali

Ini terjadi pada saya sebelumnya. Ada situasi di mana string-to-intEmacs jatuh, dan butuh waktu berjam-jam untuk menunjukkan dengan tepat juga.
Maaf saya tidak bisa memberikan jawaban yang lebih baik, tetapi crash Emacs terjadi jauh di dalam kode C, dan tidak ada alat bawaan yang tersedia untuk melacak masalah seperti itu.

Saya kira debugging dengan gdbitu mungkin, tetapi efektivitasnya akan tergantung pada kemampuan Anda gdb.

Yang perlu Anda lakukan adalah

Ajukan laporan bug

Kode elisp murni (non-byte-dikompilasi) tidak pernah seharusnya crash Emacs. Itu dapat menyebabkan hang (karena beberapa loop tak terbatas) dan itu dapat menyebabkan Emacs kehabisan memori. Tapi, lebih dari itu, semua crash adalah bug .

M-x report-emacs-bug

Cukup dengan memberikan contoh kerja minimal yang Anda buat, bersama dengan deskripsi build dan sistem Anda, akan cukup membantu pengembang yang baik hati.

— Malabarba
sumber

Menggunakan gdb akan menjadi satu-satunya cara. Kita bisa menambahkan hal-hal ke Emacs untuk membungkus setiap panggilan C dalam sesuatu yang akan menangkap sendiri tetapi itu akan menjadi overhead sepanjang waktu. Emacs tidak seharusnya macet, jika ya kita harus secara khusus menangani bug itu sehingga tidak lagi. Jadi ya, jika rusak, ajukan bug. Gunakan gdb dengan segala cara untuk mencari tahu di mana bug itu berada.

— nic ferrier

Sebagai referensi untuk debug dengan gdb, Anda ingin menggunakan src / temacs dari build tree. Ini adalah Emacs tanpa elisp pre-dumped yang membingungkan debugger.

gdb --args src/temacs -nw

— stsquad
sumber

Terima kasih, saran luar biasa (dan tidak mudah juga mencari-cari). Terima kasih.

— gsl