unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Matthew Rothlisberger <mattjrothlis@gmail.com>
Cc: 71744@debbugs.gnu.org
Subject: bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape
Date: Mon, 24 Jun 2024 15:28:23 +0300	[thread overview]
Message-ID: <86r0cmbk48.fsf@gnu.org> (raw)
In-Reply-To: <CAG3xYBCnnend0gP+2SCdoQVRhcxryO9YfmzFJCQN_zDthXz82g@mail.gmail.com> (message from Matthew Rothlisberger on Sun, 23 Jun 2024 17:16:57 -0400)

> 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.





  reply	other threads:[~2024-06-24 12:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-23 21:16 bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape Matthew Rothlisberger
2024-06-24 12:28 ` Eli Zaretskii [this message]
2024-06-26 23:27   ` Matthew Rothlisberger
2024-06-27 10:05     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86r0cmbk48.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=71744@debbugs.gnu.org \
    --cc=mattjrothlis@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).