[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Valtteri Vuorikoski
Subject: bug#40225: 27.0.90; abort with apparent stack explosion in lsp-mode
Date: Wed, 25 Mar 2020 18:25:41 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

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


On 2020-03-25 18:20, Eli Zaretskii wrote:
From: Valtteri Vuorikoski <address@hidden>
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)?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]