3

Here's the story: I'm using macOS 10.15.1 and Emacs ver. 26.3 for macOSX from the eponymous site.

Some time ago, maybe after 10.15.2 update, I started to experience frequent Emacs crashes, occurring mainly in the start of the session, whenever I try to launch shell, use grep/ag from projectile, start sly/slime session, or fetch git repo information via magit. Crashes never occur when I just edit files, open and close them, save my changes and so on.

However, it doesn't always crash, and if it doesn't at the very first attempt, it won't crash at all and I can do as I please and just continue with my work.

Now the information about crash: as I see in the Console.app, crashes are quite consistent and reproduce nicely. For the process launch case:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff71dd149a __pthread_kill + 10
1   libsystem_pthread.dylib         0x00007fff71e8e6cb pthread_kill + 384
2   libsystem_c.dylib               0x00007fff71ce93a2 raise + 26
3   Emacs-x86_64-10_14              0x00000001000bb789 terminate_due_to_signal + 153
4   Emacs-x86_64-10_14              0x00000001000d8e03 emacs_abort + 19
5   Emacs-x86_64-10_14              0x00000001001c102a ns_term_shutdown + 122
6   Emacs-x86_64-10_14              0x00000001000bb976 shut_down_emacs + 262
7   Emacs-x86_64-10_14              0x00000001000bb756 terminate_due_to_signal + 102
8   Emacs-x86_64-10_14              0x00000001000dba0e handle_fatal_signal + 14
9   Emacs-x86_64-10_14              0x00000001000dba91 deliver_thread_signal + 129
10  Emacs-x86_64-10_14              0x00000001000da629 deliver_fatal_thread_signal + 9
11  Emacs-x86_64-10_14              0x00000001000dbb4b handle_sigsegv + 171
12  libsystem_platform.dylib        0x00007fff71e83b1d _sigtramp + 29
13  ???                             000000000000000000 0 + 0
14  Emacs-x86_64-10_14              0x0000000100187ba3 setup_process_coding_systems + 163
15  Emacs-x86_64-10_14              0x0000000100189e0b create_process + 555
16  Emacs-x86_64-10_14              0x00000001001891c8 Fmake_process + 2424
17  Emacs-x86_64-10_14              0x0000000100140b18 Ffuncall + 728
18  Emacs-x86_64-10_14              0x000000010014066f Fapply + 607
19  Emacs-x86_64-10_14              0x0000000100140b18 Ffuncall + 728
20  Emacs-x86_64-10_14              0x0000000100184d3e exec_byte_code + 1838
21  Emacs-x86_64-10_14              0x0000000100140ab9 Ffuncall + 633
22  Emacs-x86_64-10_14              0x0000000100184d3e exec_byte_code + 1838
23  Emacs-x86_64-10_14              0x0000000100141ae1 funcall_lambda + 897
24  Emacs-x86_64-10_14              0x0000000100140ab9 Ffuncall + 633
25  Emacs-x86_64-10_14              0x0000000100184d3e exec_byte_code + 1838
26  Emacs-x86_64-10_14              0x0000000100141ae1 funcall_lambda + 897
27  Emacs-x86_64-10_14              0x0000000100140ab9 Ffuncall + 633
28  Emacs-x86_64-10_14              0x000000010014121a call0 + 26
29  Emacs-x86_64-10_14              0x000000010013f540 internal_condition_case_n + 288
30  Emacs-x86_64-10_14              0x00000001000c2747 safe_run_hook_funcall + 55
31  Emacs-x86_64-10_14              0x0000000100140e3d run_hook_with_args + 317
32  Emacs-x86_64-10_14              0x00000001000c097c safe_run_hooks + 108
33  Emacs-x86_64-10_14              0x00000001000f8420 Fdo_auto_save + 224
34  Emacs-x86_64-10_14              0x00000001000c41e3 read_char + 5059
35  Emacs-x86_64-10_14              0x00000001000c106a read_key_sequence + 1722
36  Emacs-x86_64-10_14              0x00000001000bf872 command_loop_1 + 1234
37  Emacs-x86_64-10_14              0x000000010013f16c internal_condition_case + 268
38  Emacs-x86_64-10_14              0x00000001000cef60 command_loop_2 + 48
39  Emacs-x86_64-10_14              0x000000010013e760 internal_catch + 272
40  Emacs-x86_64-10_14              0x00000001000be81e command_loop + 158
41  Emacs-x86_64-10_14              0x00000001000be72f recursive_edit_1 + 111
42  Emacs-x86_64-10_14              0x00000001000bea16 Frecursive_edit + 406
43  Emacs-x86_64-10_14              0x00000001000bd32d main + 6477
44  libdyld.dylib                   0x00007fff71c822e5 start + 1

When I try to fetch remotes from Magit:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff71dd149a __pthread_kill + 10
1   libsystem_pthread.dylib         0x00007fff71e8e6cb pthread_kill + 384
2   libsystem_c.dylib               0x00007fff71ce93a2 raise + 26
3   Emacs-x86_64-10_14              0x00000001000bb789 terminate_due_to_signal + 153
4   Emacs-x86_64-10_14              0x00000001000d8e03 emacs_abort + 19
5   Emacs-x86_64-10_14              0x00000001001c102a ns_term_shutdown + 122
6   Emacs-x86_64-10_14              0x00000001000bb976 shut_down_emacs + 262
7   Emacs-x86_64-10_14              0x00000001000bb756 terminate_due_to_signal + 102
8   Emacs-x86_64-10_14              0x00000001000dba0e handle_fatal_signal + 14
9   Emacs-x86_64-10_14              0x00000001000dba91 deliver_thread_signal + 129
10  Emacs-x86_64-10_14              0x00000001000da629 deliver_fatal_thread_signal + 9
11  Emacs-x86_64-10_14              0x00000001000dbb4b handle_sigsegv + 171
12  libsystem_platform.dylib        0x00007fff71e83b1d _sigtramp + 29
13  ???                             000000000000000000 0 + 0
14  Emacs-x86_64-10_14              0x000000010018ca0a connect_network_socket + 3130
15  Emacs-x86_64-10_14              0x000000010018b955 Fmake_network_process + 1973
16  Emacs-x86_64-10_14              0x0000000100140b18 Ffuncall + 728
17  Emacs-x86_64-10_14              0x0000000100184d3e exec_byte_code + 1838
18  Emacs-x86_64-10_14              0x0000000100140ab9 Ffuncall + 633
19  Emacs-x86_64-10_14              0x0000000100184d3e exec_byte_code + 1838
20  Emacs-x86_64-10_14              0x0000000100140ab9 Ffuncall + 633
21  Emacs-x86_64-10_14              0x0000000100184d3e exec_byte_code + 1838
22  Emacs-x86_64-10_14              0x0000000100140ab9 Ffuncall + 633
23  Emacs-x86_64-10_14              0x0000000100184d3e exec_byte_code + 1838
24  Emacs-x86_64-10_14              0x0000000100140ab9 Ffuncall + 633
25  Emacs-x86_64-10_14              0x0000000100139c26 Ffuncall_interactively + 70
26  Emacs-x86_64-10_14              0x0000000100140b18 Ffuncall + 728
27  Emacs-x86_64-10_14              0x0000000100139e92 Fcall_interactively + 594
28  Emacs-x86_64-10_14              0x000000010014166b funcall_subr + 299
29  Emacs-x86_64-10_14              0x0000000100140b18 Ffuncall + 728
30  Emacs-x86_64-10_14              0x0000000100184d3e exec_byte_code + 1838
31  Emacs-x86_64-10_14              0x0000000100140ab9 Ffuncall + 633
32  Emacs-x86_64-10_14              0x000000010014124c call1 + 44
33  Emacs-x86_64-10_14              0x00000001000bfb0c command_loop_1 + 1900
34  Emacs-x86_64-10_14              0x000000010013f16c internal_condition_case + 268
35  Emacs-x86_64-10_14              0x00000001000cef60 command_loop_2 + 48
36  Emacs-x86_64-10_14              0x000000010013e760 internal_catch + 272
37  Emacs-x86_64-10_14              0x00000001000be81e command_loop + 158
38  Emacs-x86_64-10_14              0x00000001000be72f recursive_edit_1 + 111
39  Emacs-x86_64-10_14              0x00000001000bea16 Frecursive_edit + 406
40  Emacs-x86_64-10_14              0x00000001000bd32d main + 6477
41  libdyld.dylib                   0x00007fff71c822e5 start + 1

System log also contains suspicious lines, but I don't know if they have any connection to the crash:

09:15:39 com.apple.xpc.launchd[1] (org.gnu.Emacs.1528[75856]): Service exited due to SIGABRT
09:20:49 Emacs-x86_64-10_14[82907]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
09:28:52 com.apple.xpc.launchd[1] (org.gnu.Emacs.1528[82907]): Service exited due to SIGABRT
09:29:13 Emacs-x86_64-10_14[83715]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
09:30:59 com.apple.xpc.launchd[1] (org.gnu.Emacs.1528.5A034B74-38F9-4465-B8F3-EE4A7D6C3D04[83715]): Service exited due to SIGABRT
09:47:18 Emacs-x86_64-10_14[83519]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
10:00:33 Emacs-x86_64-10_14[85644]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
10:02:01 com.apple.xpc.launchd[1] (org.gnu.Emacs.1528.98532F72-A7CA-48C1-AB20-CA9BA40214C0[85644]): Service exited due to SIGABRT
10:02:15 Emacs-x86_64-10_14[86431]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
10:04:42 com.apple.xpc.launchd[1] (org.gnu.Emacs.1528.12F80E4E-3872-435C-82CD-91B51957B182[86431]): Service exited due to SIGABRT
10:04:51 Emacs-x86_64-10_14[87066]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
10:06:12 Emacs-x86_64-10_14[87586]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
10:06:38 com.apple.xpc.launchd[1] (org.gnu.Emacs.1528.C07B4B1E-4019-40AA-B049-C7BA6350DC7C[87586]): Service exited due to SIGABRT
12:47:25 Emacs[45383]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
12:48:24 com.apple.xpc.launchd[1] (org.gnu.Emacs.9828.64AFFA95-874F-4701-9DBF-64AE044CA82F[45383]): Service exited due to SIGABRT
12:53:46 Emacs[46033]: assertion failed: 19B88: libxpc.dylib + 86572 [99CC9436-D653-3762-ADBB-9054EBD1BA2B]: 0x89
12:55:14 com.apple.xpc.launchd[1] (org.gnu.Emacs.9828.2CD9EA36-8700-4AF8-A1AC-1EAA9FFE9100[46033]): Service exited due to SIGABRT

I also have an impression that if I don't touch "dangerous" functions (i.e. don't launch processes/access network) for a while, the probability of crash lowers. I haven't verified it though.

Also Emacs doesn't crash when run with -q, so I suppose it has to do with packages I use, but I have no idea what can cause this, since Emacs also crashes on built-in actions like M-x shell right after I start it.

I've been haunted by this issue for almost a month, actively trying to device a fix for a week and have run out of ideas, so any help or advice would be much appreciated!

Improve this question
5
  • 1
    The best way to deal with this is to M-x report-emacs-bug or send email to [email protected]. Might also be worth trying the soon-to-be-released emacs-27
    – rpluim
    Jan 16, 2020 at 12:47
  • 1
    Let me add to what @rpluim said: a crash is the result of a bug in the C code, hence not something that Emacs users can do much about easily (Emacs is designed under the assumption that recompiling it is a serious obstacle), so SX is not a good resource for that.
    – Stefan
    Jan 16, 2020 at 13:26
  • And I've just realized that this is 'emacsformacosx', not vanilla Gnu Emacs, so perhaps check with them first.
    – rpluim
    Jan 16, 2020 at 13:51
  • @Stefan, oh, I see. I also think that since Emacs is big and old, and it should be quite a quest to compile it on non-GNU system. But still, I never tried to debug it C-way, so maybe I'll try it out.
    – alexey.e.egorov
    Jan 16, 2020 at 14:45
  • @rpluim, thanks, will try emacs-27 and update the post.
    – alexey.e.egorov
    Jan 16, 2020 at 14:47

1 Answer 1

Reset to default
2

Success! and eventually I found out what exactly happened and how to fix it.

Short version: I work on a large C++ project and use lsp + clls for code navigation. Emacs part of the lsp, lsp-mode has a number of variables, and one of them — lsp-file-watch-threshold was set to nil by me in order to silence its warning about a number of watched directories. This cause Emacs to exhaust all available file descriptors, and on the next attempt to get a descriptor Emacs crashed. That's what my lsp config looked like:

(use-package lsp-mode
  :commands lsp
  :config (setq lsp-file-watch-threshold nil
                lsp-enable-snippet nil)
  :init
  (add-hook 'rust-mode-hook #'lsp))

I set lsp-enable-file-watchers to nil and this fixed the crash. It didn't impair lsp functionality in an observable way, since directory watching purpose is to add new files to lsp workspace when they appear on the filesystem (as I understand). Final version of the lsp-mode config:

(use-package lsp-mode
  :commands lsp
  :config (setq lsp-file-watch-threshold 512
                lsp-enable-file-watchers nil
                lsp-enable-snippet nil)
  :init
  (add-hook 'rust-mode-hook #'lsp))

Long version: @Stefan's mention of C code reminded me of the possibility to go low-level. So I decided to give it a try.

I. Compiling Emacs from source was surprisingly easy. I just checked out the official repo and did everything according to INSTALL file. I only encountered two issues: missing makeinfo and misplaced libxml.h. Also after initial ./configure and make I realised that I forgot to enable debug flags and asserts, so I had to reconfigure and recompile Emacs again. Glad that it took only three minutes or so. The final Emacs debug build for macOS Catalina 10.15.2 is here:

$ ./autogen.sh # generates ./configure script
$ CFLAGS='-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/libxml2/ -ggdb3 -O0' ./configure --without-makeinfo --enable-checking
$ make -j8

II. Debugging After Emacs have successfully compiled, I launched lldb and reproduced the crash: lldb ./src/emacs was sufficient:

process.c:459: Emacs fatal error: assertion failed: fd >= 0 && fd < FD_SETSIZE
Process 54308 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff71dd149a libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff71dd149a <+10>: jae    0x7fff71dd14a4            ; <+20>
    0x7fff71dd149c <+12>: movq   %rax, %rdi
    0x7fff71dd149f <+15>: jmp    0x7fff71dcb3b7            ; cerror_nocancel
    0x7fff71dd14a4 <+20>: retq
Target 0: (emacs) stopped.

Thanks to enabled asserts, reason have become apparent. Just to be sure I checked also the frame with the assert itself:

(lldb) fr s 9
frame #9: 0x00000001003975bf emacs`add_non_keyboard_read_fd(fd=2534) at process.c:459:3
   456  static void
   457  add_non_keyboard_read_fd (int fd)
   458  {
-> 459    eassert (fd >= 0 && fd < FD_SETSIZE);
   460    eassert (fd_callback_info[fd].func == NULL);
   461
   462    fd_callback_info[fd].flags &= ~KEYBOARD_FD;
(lldb) p fd
(int) $2 = 2534

The fd is indeed greater than FD_SETSIZE, which is set to 1024 in macOS system headers. It's a great number of descriptors and I still have no idea, why Emacs would need such a large number.

So naturally I proceeded to the terminal and invoked lsof in order to reveal this secret:

$ lsof | awk '{print $1}' | uniq -c | sort -rn | grep -i emacs
 2591 emacs

And after quick glance on a lsof | grep emacs | less it become apparent that all the file descriptors opened were the directory structure of that large C++ project I'm working on.

Hope that helps someone else! Also building and debugging Emacs turned out much more friendly that I anticipated.

Improve this answer

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.