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?
gsl
  • 1,742
  • 17
  • 34
  • 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 http://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
  • @nic-ferrier @malabarba Would you mind adding an answer to point 1, so that this could be useful to others for future similar issues? Tracking the source of the bug was really time consuming. Is there any way to use an external debugger? Using @nic-ferrier's suggestion of `condition-case err` did not work in this case. – gsl Sep 27 '14 at 14:23
  • @gsl, are you saying the condition case didn't catch it? I can reproduce the seg fault over here, but wrapping it in a condition case does stop the crash, the error I get when wrapped is that :font is not a face attribute which makes sense in a -nw environment, but the crash should not happen, only the error. specifically, the error I get is: `(error "Invalid face attribute name" :face)` when condition-cased That being said, you should use `set-default-font` to set the font, not set-face-attribute. – Jordon Biondo Sep 27 '14 at 14:48
  • @jordon-biondo Yes, if I have just this line `(condition-case err (set-face-attribute 'default nil :font "Menlo-16") (error (message "Whoops!")))`, the condition case didn't catch it. I just get `Fatal error 11: Segmentation fault`. Thank you for pointing out to use `set-default-font` instead. – gsl Sep 27 '14 at 15:12
  • Looks like I typed the wrong face attribute it, ignore my comment. – Jordon Biondo Sep 27 '14 at 15:22
  • 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
  • Great. Here's wishing a fruitful followup and a fix. Thx. – Drew Sep 27 '14 at 16:15

2 Answers2

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.

legoscia
  • 6,012
  • 29
  • 54
Malabarba
  • 22,878
  • 6
  • 78
  • 163
  • 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
stsquad
  • 4,626
  • 28
  • 45