9

Although Emacs (24.3.93.1) runs fine if launched from the Finder, if the terminal version is launched:

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

Emacs crashes with:

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

It seems the issue is caused by a single line in init.el,

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

If that line is commented out, the terminal version of Emacs will start fine too.

To pinpoint the cause of the crash took me several hours (diminishing my init.el half by half).

I am aware that in any case Emacs will inherit whatever font and font size is specified in the terminal app (basically, that line is not meaningful in the cli.)

  1. Generally speaking, is there a better way to debug a crashing Emacs? Perhaps using some kind of cli debugger that would print a more descriptive message?
  2. Why is that line crashing Emacs via cli, but not if launched from the Finder?
  • is it really launching from the cli? or launching the terminal version that is causing the problem? Try putting some error catching around the set-face-attribute? (condition-case err (set-face-attribute...) (error (message "Whoops!"))) – nic ferrier Sep 27 '14 at 12:32
  • 3
    File a bug report. Emacs should never crash due to lisp code. But this may be a problem with the specific build you're using, is it the official release? – Malabarba Sep 27 '14 at 13:37
  • @nic-ferrier: I have now just one line in init.el, (condition-case err (set-face-attribute 'default nil :font "Menlo-16") (error (message "Whoops!"))) still I have the same crash with same error message. No additional elisp-originating messages. – gsl Sep 27 '14 at 14:13
  • @ malabarba: I have tried with GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org from emacsformacosx.com, and Emacs does not crash. So, it must be a bug in later versions. I shall file a bug report. – gsl Sep 27 '14 at 14:20
  • 1
    As @Malabarba indicated: File a bug report (immediately): M-x report-emacs-bug. Emacs developers will then lead you through what you can do to help debug the problem. – Drew Sep 27 '14 at 15:50
6

To help you track it next time

This happened to me before. There was a situation where string-to-int crashed Emacs, and it took me hours to pinpoint as well.
Sorry I can't provide a nicer answer, but Emacs crashes happen deep down in the C code, and there aren't any built-in tools available to track down such problems.

I suppose debugging it with gdb is possible, but its effectiveness will depend on your proficiency with gdb.

What you really need to do is

File a bug report

Pure elisp code (non-byte-compiled) is never supposed to crash Emacs. It could cause a hang (due to some infinite loop) and it could cause Emacs to run out of memory. But, beyond that, any crash is a bug.

M-x report-emacs-bug

Simply providing this minimally working example you came up with, along with a description of your build and system, should be enough help for the kind developers.

  • 2
    Using gdb would be the only way. We could add stuff to Emacs to wrap every C call in something that would self catch but that would be overhead all the time. Emacs is not supposed to crash, if it does we should specifically handle that bug so that it doesn't anymore. So yeah, if it's broken, file a bug. Use gdb by all means to find out absolutely where the bug is. – nic ferrier Sep 27 '14 at 18:39
4

As a reference to debug with gdb you'll want to use src/temacs from the build tree. This is Emacs without the pre-dumped elisp which confuses the debugger.

gdb --args src/temacs -nw
  • 1
    Thank you, excellent advice (and not easy too find around, too). Thanks. – gsl Nov 3 '14 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.