GNU bug report logs -
#79182
30.1; emacs becomes progressively less responsive up to become unusable
Previous Next
Full log
View this message in rfc822 format
> 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.
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.
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?
And finally, set garbage-collection-messages non-nil and see if Emacs
says it's running GC when it becomes not responsive.
(FTR, I see no slowdowns in my sessions, which also run for weeks.
But then I have only one screen, nothing as fancy as what you
describe.)
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.