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 didn't experience any crashes.)--daemon, and
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 {
--daemonoption. 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.sudo journalctl -xeor evendmesg | 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-bugwith your finding. See git.savannah.gnu.org/cgit/emacs.git/tree/etc/DEBUG for details.emacs --debug-init &, now I'm runningemacs --daemon --debug-init &, but (3) ... latter can be problematic, see emacs.stackexchange.com/q/27376/5444M-x report-emacs-bug.