bug#72025: SEGFAULT when using corfu and lsp-mode with clangd

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: ravijdelia@gmail.com,  72025@debbugs.gnu.org
> Date: Wed, 10 Jul 2024 10:07:28 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: 72025@debbugs.gnu.org
> >> From: Andrea Corallo <acorallo@gnu.org>
> >> Date: Wed, 10 Jul 2024 04:06:02 -0400
> >> 
> >> Ravi D'Elia <ravijdelia@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.