Subject: Re: bug#79182: 30.1; emacs becomes progressively less responsive up to become unusable

From: Francesco Potortì <[email-masked]>
Date: Wed, 06 Aug 2025 16:57:19 +0200

>> From: Francesco Potortì <[email-masked]>
>> 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