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?
10
  • 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!"))) Sep 27, 2014 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, 2014 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, 2014 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, 2014 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, 2014 at 15:50

2 Answers 2

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.

1
  • 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. Sep 27, 2014 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
  • 1
    Thank you, excellent advice (and not easy too find around, too). Thanks.
    – gsl
    Nov 3, 2014 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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