GNU bug report logs - #40225
27.0.90; abort with apparent stack explosion in lsp-mode

Previous Next

Full log

Message #35 received at 40225 <at> debbugs.gnu.org (full text, mbox):

From: Valtteri Vuorikoski <vuori <at> notcom.org>
To: 40225 <at> debbugs.gnu.org
Subject: Re: bug#40225: 27.0.90; abort with apparent stack explosion in
 lsp-mode
Date: Fri, 15 May 2020 10:28:58 +0300

On 2020-03-31 18:53, Eli Zaretskii wrote:
>> (gdb) bt full 3
>> #0  0x00005568e2e5dc1b in mark_object (arg=Python Exception <class
>> 'gdb.MemoryError'> Cannot access memory at address 0x7ffde9c2fff8:
>> #1  0x00005568e2e5df9c in mark_object (arg=0x5568e6c1f003) at alloc.c:6629
>>           ptr = 0x5568e6c1f000
>>           obj = 0x5568e6c1f043
>>           po = 0x5568e6c1f000
>>           cdr_count = 0
> 
> This does look like stack overflow.  Can you enlarge the stack size of
> your Emacs and see if that helps?
> 

After fiddling with my init.el, the crash seems to have gone away even 
with stack limit set to 8MB. I can't state the culprit with full 
certainty, but with ~75% probability it was a function 
(tab-line-tabs-buffer-list-function) which was getting called on every 
mouse event.

Since this function was getting called a huge number of times, I 
memoized some parts of it with the memoize.el library. It generates a 
closure like this: 
https://github.com/skeeto/emacs-memoize/blob/master/memoize.el#L99

If a timeout is set, every time the lambda is called, the cleanup timer 
is reset. Crashes stopped after I removed the timeout from my memoized 
function. There were a few other tweaks and package updates around the 
same time, but as far as I can tell this was the only high-traffic 
function that changed.

 -Valtteri

Previous Next

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