bug#40225: 27.0.90; abort with apparent stack explosion in lsp-mode

[Valtteri Vuorikoski]

Unfortunately there is nothing printed when emacs dies, which is weird 
in itself. zsh just shows that the background process exited with "abort".

I'll make a non-optimized build and see if I can catch a better 
backtrace tomorrow.

("Stack overflow" was a misnomer in the original report, I meant that 
the process may be hitting a stack size limit. "ulimit -a" shows 8MB 
stack limit.)

 -Valtteri


On 2020-03-25 18:20, Eli Zaretskii wrote:
> > From: Valtteri Vuorikoski <vuori@notcom.org>
> > Date: Wed, 25 Mar 2020 16:03:35 +0200
> >
> > Emacs crashes 1-3 times a day with SIGABRT, usually when editing a
> > buffer in lsp-mode. There is no sure way to reproduce the crash, but it
> > usually appears after a few hours of using lsp-mode and usually when
> > scrolling the buffer.
> >
> > I haven't been able to reproduce this from emacs -Q because it requires
> > several hours of heavy use to appear, and I can't get much done
> > with -Q.
> >
> > This crash never happened with Emacs 26.1.
> >
> > Possible related: gc-cons-threshold is set to 16MB (ddskk is very slow
> > with the default value).
> >
> > gdb stack trace looks like stack was exhausted (sorry, no bt
> > full/xbacktrace, I'll try to get those on next crash):
>
> SIGABRT is unlikely to be caused by stack overflow.  Stack overflow
> usually causes SIGSEGV.
>
> Can you please show the full crash message, including the "program
> received signal SIGABRT" part?
>
> Also, this is an optimized build, so the backtrace is not really
> reliable.  Can you build Emacs without optimizations and show a
> backtrace from there (assuming it still crashes in the same manner
> when built that way)?
>
> Thanks.