GNU bug report logs - #79023
30.1.90; Suspicion of memory leak on internal_redisplay (MacOS)

Previous Next

Full log

View this message in rfc822 format

From: Przemysław Alexander Kamiński
 <przemyslaw <at> kaminski.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79023 <at> debbugs.gnu.org
Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS)
Date: Tue, 15 Jul 2025 15:01:55 +0200

[Message part 1 (text/plain, inline)]

On 15 Jul 2025, at 14:23, Eli Zaretskii wrote:

> Given the above description, why did you decide the leak is in
> redisplay_internal?

     39,652,925  72% - redisplay_internal (C function)
      1,797,080   3%  + eval
        279,056   0%  + jit-lock-function
         66,632   0%  + which-key--hide-popup-on-frame-size-change
         24,752   0%    mode-line-default-help-echo
         11,328   0%  + menu-bar-update-buffers

This is taken from just now. It seems like a lot of memory goes there. 
Given that I have 2Gbs of usage beyond ~40mb reporting I'd suspect 
something fishy is happening there.

And on paper everything looks fine - with single Elisp buffer Emacs 
reports: 57MiB as reserved for objects, ~30mb of Conses. There is 900Mb 
of total system usage which makes it top memory eater.

For context - I run HiDPI and refresh rate system though (4400x2400 with 
60hz - was 144hz before), which might explain why redisplay memory rise 
is happening quicker than for others.

>
> FWIW, I'm using Emacs 30.1.90 all the time, with sessions that last
> several weeks, and its memory footprint, after leveling at several
> hundred MB never grows more, certainly not at the rate you describe.
> So either this is a macOS-specific problem, or something else is at
> work here (perhaps one of the many packages you have activated?).

I'm quite sure that this is the problem with MacOS/NS implementation.

I've experienced similar behavior in raw and patched versions and rarely 
can hold a session for more than 2 days. Usually when Emacs went dead it 
went dead and that was it, I blamed it on setup, only today caught bloat 
when I was investigating performance deterioration. (and searching for 
it the general complain is "well Emacs on MacOS is slower than on 
Linux").

> Well, for starters please explain why you think it's
> redisplay_internal that leaks.  Also, if you can try older versions of
> Emacs, please see if the same issue exists there.

I'm quite positive it does, because I've observed this for at least 2 
years. Today it's much better than it was before, but still it bloats. I 
didn't think about running -Q, and that was simple enough to confirm 
that:

      1,561,924  54% + timer-event-handler
      1,185,948  41% - redisplay_internal (C function)
        287,011  10%  + jit-lock-function
         79,104   2%    file-remote-p
         13,312   0%  + kill-this-buffer-enabled-p
          8,184   0%    mode-line-default-help-echo

Usage is 230MiB of memory, reported 5MiB. leaks app (MacOS malloc leak 
tracer) reports barely 229kb of leaked memory and it reports 37MiB 
malloced out of 139MiB (usage dropped while I was writing this e-mail). 
Finally - redisplay_internal is the only place I saw memory going out 
(and just noticed that redisplay itself is good enough to start GC every 
couple seconds - 17GCs over 10s test period using -Q instance).

>
> And finally, what version of Emacs are you using and how did you build
> it?  Is that Emacs 30.1.90 pretest built from the pretest tarball, or
> is it something else?

MacOS built with emacs-plus - built through Homebrew from emacs-30 
branch right now, but I've seen this performance degredation over time 
on emacs-mac and emacs through MacPorts.

Best,
Przemysław Alexander Kamiński

[Message part 2 (text/html, inline)]

Previous Next

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