I generally have a long-running instance of emacs --daemon, which I connect to with various emacsclients. Recently I have started experiencing random crashes. I say "random" because I haven't been able to figure out what causes the crashes. Often it happens e.g. when I leave my work computer over the weekend. However, I also remember at least one time when I started Emacs again after a crash, and it crashed again after a couple hours, during the same session.

I started an instance with emacs -Q (and then did M-x server-start) on my unused laptop, and it has not crashed yet. (Currently it has been: about a week.) One day I had need to use Emacs on that laptop, so I started up a separate session by doing emacs from a terminal window, and did not start the server. I left that session running, and when I came back a day or two later, I found that it had crashed, giving Segmentation fault. Thus, it would seem that this is not related to running Emacs in daemon mode.

I would do a binary search of my init file, but due to the randomness of the crashes, it would be a pain to go without much of the functionality I'm used to for an extended amount of time. Also, I wouldn't have a good way to know when I had fixed it, and the crashes weren't occuring.

I use Emacs 24.4, on Debian GNU/Linux 8, and on Ubuntu. (I have used Emacs on Windows before, but didn't use the --daemon, and didn't experience any crashes.)

How else can I debug these random crashes?

Edit: I get the same result when I launch Emacs and then do M-x server-start, and also when I use the Lucid toolkit.

I ran gdb emacs, and then at the (gdb) prompt did run, and this was the output:

Starting program: /usr/bin/emacs
[Thread debugging using libthread_db_enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-io8859-*" to type FontStruct

(Note that the last line also appears as terminal output when I launch Emacs outside of GDB.)

In Emacs, I did M-x server-start, and started work. It didn't crash all day, so I left it running over the weekend. When I got back today, I found Emacs unresponsive, and this additional output in GDB:

Program received signal SIGSEGV, Segmentation fault.
mark_object (arg=42366066) at alloc.c:5601
5601    alloc.c: No such file or directory.

After that line, control returned to the GDB prompt.

Edit 2: After building Emacs from source, I again ran it from GDB and did M-x server-start. Today I again found it unresponsive, and this was the output in GDB:

Starting program: [snip]/emacs-24.5/src/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffee188700 (LWP 20124)]
[New Thread 0x7fffe7df2700 (LWP 20125)]
[New Thread 0x7fffe75f1700 (LWP 20126)]

Program received signal SIGSEGV, Segmentation fault.
mark_object (arg=47086818) at alloc.c:5973
5973    {
  • 2
    I experienced the same. There is a warning that emacs (GTK) might crash when you launch with --daemon option. Not sure if it is related, you could try the lucid toolkit. I now just launch emacs with (server-start) in my init file and get the same client/server behavior. – Lompik May 11 '15 at 3:24
  • Good point. I had seen that warning, but thought it was only a problem when restarting my X session. I'll report back after I've done some testing with the Lucid toolkit. – Scott Weldon May 11 '15 at 3:34
  • Crashed again while running the Lucid toolkit. Unfortunately, it looks like this isn't the problem. I'll try out your other suggestion, and see if it makes a difference if I run Emacs normally and then do M-x server-start. – Scott Weldon May 13 '15 at 15:33
  • 2
    there should be a trace of something like "emacs dumped core" in sudo journalctl -xe or even dmesg | grep emacs. My point is that is is possible to anlyse the core dump file and get a backtrace. In any case, you could launch emacs from gdb and get a backtrace of the last function called before the the crash. Basically, I would try to get as much info as possible to get rid of the randomness and make it reproducible. This might or not take some time but one it is, M-x report-emacs-bug with your finding. See git.savannah.gnu.org/cgit/emacs.git/tree/etc/DEBUG for details. – Lompik May 13 '15 at 16:57
  • 1

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.