クラッシュしたEmacsのより良いデバッグ？

Emacs（24.3.93.1）は、Finderから起動すると問題なく動作しますが、ターミナルバージョンを起動すると、次のようになります。

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

Emacsは次のようにクラッシュします：

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

問題はinit.elの1行によって引き起こされているようです。

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

その行がコメント化されている場合、Emacsのターミナルバージョンも正常に起動します。

クラッシュの原因を特定するのに数時間かかりました（init.elが半分ずつ減少しました）。

Emacsは、ターミナルアプリで指定されたフォントとフォントサイズを継承します（基本的に、この行はCLIでは意味がありません）。

1. 一般的に言えば、クラッシュするEmacsをデバッグするより良い方法はありますか？おそらく、より説明的なメッセージを出力するようなある種のcliデバッガーを使用していますか？
2. その行がcliを介してEmacsをクラッシュさせるのに、Finderから起動したのではないのはなぜですか？

次回の追跡に役立てるため

これは以前私に起こりました。string-to-intEmacs がクラッシュするという状況があり 、それを特定するのにも何時間もかかりました。
申し訳ありませんが、より適切な回答を提供することはできませんが、EmacsのクラッシュはCコードの奥深くで発生し、そのような問題を追跡するための組み込みツールはありません。

でデバッグgdbできると思いますが、その効果はの熟練度に依存しますgdb。

あなたが本当にする必要があるのは

バグレポートを提出する

純粋なelispコード（非バイトコンパイル）がEmacsをクラッシュさせることは決してありません。（何らかの無限ループのために）ハングする可能性があり、Emacsがメモリ不足になる可能性があります。しかし、それ以上のクラッシュはバグです。

M-x report-emacs-bug

思いついたこの最小限に機能する例を、ビルドとシステムの説明とともに提供するだけで、親切な開発者にとって十分な助けになるはずです。

gdbを使用したデバッグのリファレンスとして、ビルドツリーからsrc / temacsを使用する必要があります。これは、デバッガを混乱させる事前ダンプされたelispのないEmacsです。

gdb --args src/temacs -nw