GNU bug report logs - #79182
30.1; emacs becomes progressively less responsive up to become unusable

Previous Next

Full log

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

From: Francesco Potortì <pot <at> potorti.it>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79182 <at> debbugs.gnu.org
Subject: Re: bug#79182: 30.1;
 emacs becomes progressively less responsive up to become unusable
Date: Wed, 06 Aug 2025 19:06:03 +0200

>> I just did that and yes, when Emacs stalls it is always because of the garbage collector.
>
>Aha!
>
>> Estimated Emacs Memory Usage
>> 
>>    4.9 GiB  Total Buffer Memory Usage
>>    3.5 GiB  Overall Object Memory Usage
>>    291 MiB  Reserved (But Unused) Object Memory
>>     22 MiB  Memory Used By Global Variables
>>    6.4 MiB  Memory Used By Symbol Plists
>>    134 KiB  Total Image Cache Size
>> 
>> Object Storage
>> 
>>    2.2 GiB  Intervals
>>    1.2 GiB  Conses
>>     51 MiB  Strings
>>     22 MiB  Vectors
>>    2.5 MiB  Symbols
>>    217 KiB  Buffer-Objects
>>     11 KiB  Floats
>> 
>> Largest Buffers
>> 
>>    3.1 GiB  *debug tramp/scp evaalapi-as*
>>    549 MiB  *debug tramp/scp fencepost.gnu.org*
>>    321 MiB  *debug tramp/scp casapot*
>>    312 MiB  *debug tramp/scp aaloa*
>>    287 MiB   *message-viewer RMAIL*
>>    181 MiB  *debug tramp/scp rootevaal*
>>    125 MiB  *debug tramp/scp evaalapi-eu*
>
>That's a _huge_ session.
>
>> After deleting all the *debug tramp buffers, the problem seems to have disappeared.  I have used Emacs for some minutes after that, and it behaves normally.  The huge *debug tramp/scp evaalapi-as* buffer was relative to a file that was modified, on a shaky Internet connection.  So that is the first suspect.  All the other *debug tramp buffers were relative to unmodified files or deleted buffers.
>> 
>> This is the memory report after deleting all the Tramp buffers (was very fast):
>> 
>> Estimated Emacs Memory Usage
>> 
>>    456 MiB  Reserved (But Unused) Object Memory
>>    388 MiB  Total Buffer Memory Usage
>>    112 MiB  Overall Object Memory Usage
>>     22 MiB  Memory Used By Global Variables
>>    6.4 MiB  Memory Used By Symbol Plists
>>     73 KiB  Total Image Cache Size
>> 
>> Object Storage
>> 
>>     51 MiB  Strings
>>     31 MiB  Conses
>>     22 MiB  Vectors
>>    6.1 MiB  Intervals
>>    2.5 MiB  Symbols
>>    194 KiB  Buffer-Objects
>>     11 KiB  Floats
>
>This is much more reasonable, similar to what I have here.
>
>> Largest Buffers
>> 
>>    287 MiB   *message-viewer RMAIL*
>>     40 MiB  *eww*
>> 
>> Largest Variables
>> 
>>    2.2 MiB  woman-topic-all-completions
>>    1.4 MiB  undo-equiv-table
>>    1.3 MiB  anything-candidate-cache
>>    1.3 MiB  kill-ring
>>    1.3 MiB  kill-ring-yank-pointer
>>    1.2 MiB  anything-c-man-pages
>
>So I guess the mystery is solved?

Thanks, Eli, for guiding me till here.  Okay, now that I know the cause, I am able to correct the problem once I see it and maybe even to prevent it.

But is it normal that I get a warning when reading a file whose size exceeds a given threshold, but not when a hidden buffer grows over 3GB?

And is it normal that a 3GB buffer which is occasionally appended to has such a big impact on Emacs, even on a system with 64GB real memory available and largely unused?

And is it normal that such frequent garbage collections are not detected and signaled, with possibly a hint of what might be the most common causes and remedies?

I can easily see possible mitigations for the first and last issues, but I don't know enough to have an opinion about the second issue.

Previous Next

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