Package: emacs;
Reported by: Francesco Potortì <pot <at> potorti.it>
Date: Wed, 6 Aug 2025 09:32:02 UTC
Severity: normal
Found in version 30.1
Message #11 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 16:57:19 +0200
>> From: Francesco Potortì <pot <at> potorti.it>
>> Date: Wed, 06 Aug 2025 11:30:58 +0200
>>
>> I usually launch Emacs and do not exit it for weeks. I run the Debian emacs-lucid build running on three terminals: the Screen terminal emulator, an X Windows terminal displayed on two physical side-by-side monitors and a remote X Windows terminal managed by Xpra (a sort of graphic Screen). I use remotely both the terminal managed by Screen and the one managed by Xpra.
>>
>> Starting some months ago (maybe six months?) I have observed that Emacs becomes gradually less responsive to user keypresses, to the point that it slows down my workflow significantly. Restarting it solves the problem. The effect is very gradual, and becomes unbearable after two or three weeks. For example, now I am at the point of having to restart Emacs and I see that ~/.emacs.desktop.lock is dated 18 July, which is 20 days ago.
>>
>> The effect I observe is a noticeable delay from the moment I press a key to the moment I see the effect on Emacs, on any terminal. This is less evident while I am writing without pauses such as in this moment. I observe next to no delay while writing. But after any pause, which may be even one or two seconds long, I observe delays of at least half a second and up to some seconds from a keypress to Emacs reacting to it. This happens with any Emacs command, including self-insert-command. The effect is particularly grave on graphics terminals and complex buffers. I just observed a delay of more than 10s on an Eww buffer after a PgDn keypress. Occasionally I observe an even more wrringoy behaviour. If keep pressing keys when Emacs is stalled, I see that the first keypresses are lost, which sometimes causes unpredictable behaviour.
>>
>> Since the problem builds up gradually in the course of many days, I have never considered reproducing it under emacs -Q, but now that the problem does not go away with ebia ugDpnrades and has gone on for several months at least, I am wondering how I can try to debug it. I need some guidance on that, because I have not programmed in C for at least ten years by now, and while I was used to use gdb, I have never been proficient at debugging complex situations.
>>
>> One possibility would be that Emacs responsiveness degrades even if it is not used. So I may run an emacs -Q process and let it run there, unused, with only some activity running in the background, like for example display-time.
>>
>> If I am not wrong I should follow something along these steps:
>> 1) download some Emacs snapshot and compile it with debugging symbols
>> 2) run it as usual under gdb
>> 3) run inside Screen under gdb one more emacs -Q
>> 4) run inside Screen under gdb one more emacs -Q and M-x display-time
>>
>> Before trying to do that I need to know if the symptoms I describe are somewhat known already and if I can do some debuggiong at the elisp level before resorting to gdb. If I need gdb, I'd use some help with details of the steps 1-4 above.
>
>I don't think GDB is the first tool to try, at least not yet. I'd
>start from invoking "M-x profiler-start RET RET" (use the "cpu"
>profile), then press some keys which produce these long delays, then
>invoke "M-x profiler-report" and post the fully-expanded profile here.
>Maybe that will tell us something if the profile shows something
>unusual that takes a lot of CPU.
Ok, doing that next.
>Another thing to look at is the list of timers (use "M-x list-timers")
>where you might see some idle timers that take too much time before
>Emacs notices your keypresses and stops them.
I killed all the paren-el and display-time timers, and all the Tramp dired and shell processes and I got some improvements, but no significant change. Here is the current list of timers:
28.0s 1m display-time-event-handler
28.0s 1m appt-check
44m 7.5s 1h url-cookie-write-file
13h 53m 28.0s 1d diary
13h 54m 28.0s 1d sunrise-sunset
* 0.5s :repeat blink-cursor-start
* 2.0s t garbage-collect
* 30.0s - desktop-auto-save
>Yet another aspect is the memory footprint of Emacs: if it is very
>large, perhaps your system runs out of physical memory and starts
>paging?
I have RSS of about 5GB for Emacs and about 6GB for Firefox, which should not be a lot given that I have 64 GB physical memory. Anyway, I killed Firefox and I got some little improvement, but not so much.
>And finally, set garbage-collection-messages non-nil and see if Emacs
>says it's running GC when it becomes not responsive.
I just did that and yes, when Emacs stalls it is always because of the garbage collector.
Ok, I enabled the profiler and I got five garbage collections in few seconds while doing nothing special (writing this email, switching buffers and frames):
24756 98% Automatic GC
165 0% + redisplay_internal (C function)
64 0% + quail-input-method
60 0% + command-execute
6 0% + comint-output-filter
5 0% + timer-event-handler
3 0% + #<byte-code-function 821>
0 0% ...
Then I did it again, I just moved the cursor up and down in the email buffer without scrolling and got this after the first gc message:
4985 97% Automatic GC
129 2% + redisplay_internal (C function)
15 0% - command-execute
12 0% - funcall-interactively
12 0% - previous-line
12 0% line-move
3 0% - byte-code
3 0% - read-extended-command
3 0% - read-extended-command-1
3 0% - completing-read-default
3 0% redisplay_internal (C function)
0 0% ...
Once more, this time only up about twenty lines and down about the same, then stop and wait, in few seconds gc starts and I get this report:
5009 95% Automatic GC
225 4% redisplay_internal (C function)
14 0% - command-execute
13 0% - byte-code
13 0% - read-extended-command
13 0% - read-extended-command-1
13 0% completing-read-default
1 0% - funcall-interactively
1 0% - mail-abbrev-next-line
1 0% - apply
1 0% - format-addresses
1 0% - let
1 0% - condition-case
1 0% - apply
1 0% - #<native-comp-function mail-abbrev-next-line>
1 0% - next-line
1 0% line-move
0 0% ...
Again:
4929 97% Automatic GC
111 2% redisplay_internal (C function)
11 0% - command-execute
11 0% - byte-code
11 0% - read-extended-command
11 0% - read-extended-command-1
11 0% - completing-read-default
8 0% redisplay_internal (C function)
0 0% ...
Here is the output from garbage-collect:
(garbage-collect)
((conses 16 81444277 18789660)
(symbols 48 55477 35)
(strings 32 397453 30037)
(string-bytes 1 40910325)
(vectors 16 133975)
(vector-slots 8 2631311 445393)
(floats 8 1435 25028)
(intervals 56 42472026 201)
(buffers 992 223))
Here is the memory report (took a very long time to complete):
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*
40 MiB *eww*
11 MiB *message-viewer NOTIZIE*
9.7 MiB *code-conversion-work*
6.1 MiB RMAIL
5.2 MiB *info*
3.3 MiB *message-viewer GNU*
1.5 MiB loaddefs.el.gz
1.4 MiB *message-viewer hacker*
1.2 MiB *jka-compr-wr-temp*
1.1 MiB *Buffer List*
1 MiB log
1021 KiB *Messages*
915 KiB dpkg.log.1
Largest Variables
2.2 MiB woman-topic-all-completions
1.4 MiB undo-equiv-table
1.3 MiB anything-candidate-cache
1.2 MiB anything-c-man-pages
1.2 MiB kill-ring
1.2 MiB kill-ring-yank-pointer
1 MiB load-history
1 MiB ucs-normalize-hangul-translation-alist
814 KiB mailcap--computed-mime-data
725 KiB url-domsuf-domains
659 KiB package-archive-contents
618 KiB easy-menu-converted-items-table
399 KiB Info-toc-nodes
314 KiB uni-confusable-table
299 KiB pending-undo-list
269 KiB help-definition-prefixes
251 KiB current-load-list
216 KiB face--new-frame-defaults
203 KiB mailcap-mime-extensions
135 KiB mail-aliases
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
Largest Buffers
287 MiB *message-viewer RMAIL*
40 MiB *eww*
11 MiB *message-viewer NOTIZIE*
9.7 MiB *code-conversion-work*
6.1 MiB RMAIL
5.2 MiB *info*
3.3 MiB *message-viewer GNU*
1.5 MiB loaddefs.el.gz
1.4 MiB *message-viewer hacker*
1.2 MiB *jka-compr-wr-temp*
1 MiB *Messages*
1 MiB log
915 KiB dpkg.log.1
875 KiB *mail*
753 KiB dpkg.log.2.xz
622 KiB pot.bib
593 KiB *info*<5>
593 KiB *info*<3>
593 KiB *info*<4>
592 KiB *info*<2>
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
1 MiB load-history
1 MiB ucs-normalize-hangul-translation-alist
814 KiB mailcap--computed-mime-data
725 KiB url-domsuf-domains
659 KiB package-archive-contents
618 KiB easy-menu-converted-items-table
399 KiB Info-toc-nodes
314 KiB uni-confusable-table
269 KiB help-definition-prefixes
251 KiB current-load-list
216 KiB face--new-frame-defaults
203 KiB mailcap-mime-extensions
135 KiB mail-aliases
126 KiB global-map
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.