GNU bug report logs - #72025
SEGFAULT when using corfu and lsp-mode with clangd

Previous Next

Full log

View this message in rfc822 format

From: Ravi D'Elia <ravijdelia <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andrea Corallo <acorallo <at> gnu.org>, 72025 <at> debbugs.gnu.org
Subject: bug#72025: SEGFAULT when using corfu and lsp-mode with clangd
Date: Wed, 10 Jul 2024 11:27:00 -0400

On 24/07/10 05:37PM, Eli Zaretskii wrote:
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: ravijdelia <at> gmail.com,  72025 <at> debbugs.gnu.org
>> Date: Wed, 10 Jul 2024 10:07:28 -0400
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Cc: 72025 <at> debbugs.gnu.org
>> >> From: Andrea Corallo <acorallo <at> gnu.org>
>> >> Date: Wed, 10 Jul 2024 04:06:02 -0400
>> >>
>> >> Ravi D'Elia <ravijdelia <at> gmail.com> writes:
>> >>
>> >> > At unpredictable times while editing c++ files, emacs will segfault.
>> >> > I haven't been able to reproduce without lsp-mode, but with how
>> >> > unpredictable this is I don't think that necessarily means much.
>> >> > The problem exists with and without native compilation- this
>> >> > report assumes without.
>> >> >
>> >> > STEPS TO REPRODUCE:
>> >> > - Let '~/minimal' contain the attached init file
>> >> > - Start emacs with 'emacs --init-directory ~/minimal'
>> >> > - Open a c++ file
>> >> > - Edit it, taking care to type quickly and go back to edit within
>> >> >   words. I can usually get a crash within 10 minutes, but I haven't
>> >> >   been able to iterate enough to figure out exactly what is
>> >> >   happening. It's always while typing though, I think in response
>> >> >   to a keydown.
>> >> >
>> >> > Attached is the init file I used to reproduce this, and the backtrace.
>> >> > I had issues with the .gdbinit, which I will hopefully address when
>> >> > I get back from vacation.
>> >> >
>> >>
>> >> Hi Ravi,
>> >>
>> >> thanks for reporting, how did you produce the stack trace?  I ask
>> >> because without function names in it is not very useful.
>> >>
>> >> Here we have some information on how to process backtraces when Emacs
>> >> crashes [1] and here [2] some info on how to run Emacs under gdb (and
>> >> produce the backtrace there).
>> >>
>> >> Probably debugging Emacs under gdb would be the best option here.
>> >
>> > I think he already ran Emacs from GDB, but his Emacs is stripped of
>> > debugging symbols, so GDB couldn't display anything useful.  So the
>> > procedures you mention will not help.
>>
>> Right, do you we if typically distros strip our binary and this is
>> probably the case?
>
>I don't know if this is the rule (I think the rule is to offer a
>separate package with debug info, and if GDB supports debuginfod
>servers, it can download the debug info at the beginning of a
>session).  But clearly in this case the binary was stripped by
>someone.

Sorry about the backtrace, I did indeed use gdb but didn't have
the debugging symbols to make it useful. My distro (arch) does
ship a stripped binary with a separate debug package but I'm having
difficulties due to (I think) some packaging mishap on my end.  While
I take that up on my distro's forum, I'm going to try and build with
debugging info. I'll send in the backtrace when one of these bears
fruit. Didn't expect to have my computer on me, otherwise I would have
figured this out first.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.