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

[Valtteri Vuorikoski <vuori@notcom.org>]

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