bug#50284: 28.0.50; Emacs crashes occasionally on macOS BigSur

[Eli Zaretskii]

> Date: Tue, 31 Aug 2021 01:08:17 +0530
> From:  Umar Ahmad via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I haven't been able to reproduce this considering emacs crashes
> in maybe once a week or so but it usually happens while opening a file
> in a new project. I have lsp-mode enabled, so that can be a possible
> cause here, considering that is probably the only extra thing that
> initializes when opening the file in the new project.
> 
> I've installed Emacs through the brew formula hosted at
> https://github.com/d12frosted/homebrew-emacs-plus
> 
> The command used was:
> brew install emacs-plus@28 --with-xwidgets --with-native-comp

Thank you for your report.

> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib         0x00007fff203e192e __pthread_kill + 10
> 1   libsystem_pthread.dylib       0x00007fff204105bd pthread_kill + 263
> 2   libsystem_c.dylib             0x00007fff202f4bd5 raise + 26
> 3   org.gnu.Emacs                 0x000000010f646922 terminate_due_to_signal 
> + 167
> 4   org.gnu.Emacs                 0x000000010f647021 emacs_abort + 15
> 5   org.gnu.Emacs                 0x000000010f612b5a ns_term_shutdown + 119
> 6   org.gnu.Emacs                 0x000000010f5267ce shut_down_emacs + 339
> 7   org.gnu.Emacs                 0x000000010f6468f0 terminate_due_to_signal 
> + 117
> 8   org.gnu.Emacs                 0x000000010f54078c handle_fatal_signal + 14
> 9   org.gnu.Emacs                 0x000000010f5407fe deliver_thread_signal + 
> 114
> 10  org.gnu.Emacs                 0x000000010f53f2aa 
> deliver_fatal_thread_signal + 9
> 11  libsystem_platform.dylib       0x00007fff20455d7d _sigtramp + 29
> 12  ???                           0x0000000000001e99 0 + 7833
> 13  libsystem_c.dylib             0x00007fff20365406 abort + 125
> 14  org.gnu.Emacs                 0x000000010f56f396 re_match_2_internal + 
> 17627

We need to know where in regex-emacs.c is the place shown in the last
line above.  Can you try establishing that?

> 15  org.gnu.Emacs                 0x000000010f56ac4e rpl_re_search_2 + 2634
> 16  org.gnu.Emacs                 0x000000010f56a1fe rpl_re_search + 37
> 17  org.gnu.Emacs                 0x000000010f563c00 string_match_1 + 406
> 18  org.gnu.Emacs                 0x000000010f598e0c funcall_subr + 292
> 19  org.gnu.Emacs                 0x000000010f5986a3 Ffuncall + 660
> 20  s-aaf786a9-6de971fe.eln       0x0000000169c69e50 
> F732d6d6174636865733f_s_matches_0 + 128

This indicates that you are using s.el, which makes tracking this bug
harder.

> 21  org.gnu.Emacs                 0x000000010f59919e funcall_lambda + 682
> 22  org.gnu.Emacs                 0x000000010f59919e funcall_lambda + 682
> 23  org.gnu.Emacs                 0x000000010f59919e funcall_lambda + 682
> <-- truncated - same line repeated 488 times -->
> 511 org.gnu.Emacs                 0x000000010f59919e funcall_lambda + 682

And this seems to indicate a possible infinite recursion in some Lisp
program you were running.

So I think we need to see the full Lisp backtrace when this happens,
or at least the Lisp code which runs.