bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape

[Eli Zaretskii]

> From: Matthew Rothlisberger <mattjrothlis@gmail.com>
> Date: Sun, 23 Jun 2024 17:16:57 -0400
> 
> Since updating to 29.4, my Emacs has suffered segmentation faults when I 
> attempt my usual Rust
> programming workflow. 
> 
> The crash occurs during live update of a Corfu completion window in a buffer 
> containing Rust code, with
> lsp-mode enabled and connected to rust-analyzer.
> 
> When I first triggered the bug, quick inputs (like rolling a finger from key 
> to key) which changed the current
> completion list, would cause the crash.
> 
> With my minimal configuration, the most effective reproduction is to trigger 
> completion on a pair of characters,
> for which different completions appear if their order is swapped, then 
> transpose them until the crash occurs.
> 
> The crash seems to only happen when the cape-capf-buster function from Cape 
> is installed to refresh the
> completion candidates.
> 
> I did not succeed in reproducing this issue with the clangd LSP backend.
> 
> I know that this is a bug in Emacs because it occurs in 29.4 and not in 29.3, 
> with no changes to any other
> piece of the system. A cursory check indicates no issue on dev version 
> 31.0.50.173746.
> 
> Thank you for reading. See below for specific information.

Thanks, but we need a full GDB backtrace in order to investigate this,
since your use case involves a lot of moving parts that are not part
of Emacs.

> * Output from coredumpctl gdb
> (gdb) bt full
> #0  0x00007a516d01fe44 in ?? () from /usr/lib/libc.so.6
> No symbol table info available.
> #1  0x00007a516cfc7a30 in raise () from /usr/lib/libc.so.6
> No symbol table info available.
> #2  0x0000588eed79a982 in ?? ()
> No symbol table info available.
> #3  0x0000588eed79b75a in ?? ()
> No symbol table info available.
> #4  0x0000588eeda4a545 in ?? ()
> No symbol table info available.
> #5  <signal handler called>
> No symbol table info available.
> #6  0x0000588eed99a22b in ?? ()
> No symbol table info available.
> #7  0x0000588eed8ef5f1 in ?? ()
> No symbol table info available.
> ... (and so on for dozens of lines (this is the case even with debuginfo 
> loaded))

How many dozens?  Could it indicate some kind of infinite recursion
(followed by C stack overflow)?

Anyway, please run Emacs under GDB, and show the backtrace produced by
GDB.  I'm guessing your Emacs binary is stripped of debug symbols
(thus the ?? question marks instead of function names), in which case
please rebuild Emacs with debug info and don't strip it.

> (gdb) xbacktrace
> Undefined command: "xbacktrace".  Try "help".

"xbacktrace" is defined by src/.gdbinit in the Emacs source tree.  If
you don't have the sources, you can download them from the nearest GNU
FTP site.

Thanks.