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

Previous Next

Full log

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

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

> From: Przemysław Alexander Kamiński
>  <przemyslaw <at> kaminski.se>
> Cc: 79023 <at> debbugs.gnu.org
> Date: Tue, 15 Jul 2025 15:01:55 +0200
> 
> 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.

This is not relevant.  The so-called "memory profiler" doesn't
profile memory usage, it just uses calls to memory-allocation
functions as an opportunity to profile Emacs.  So what your profile
says is that redisplay_internal was used a lot, but not that there's a
memory leak in it.

>  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.

Then let's hear from other macOS users: does anyone else who uses
Emacs on macOS have similar experience wrt the Emacs memory footprint?

In any case, almost all of the code in redisplay_internal is not macOS
specific, so if there's a memory leak there, it is unlikely to affect
only the macOS build of Emacs.

>   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).

See above: your interpretation of the "memory profile" is wrong.  In
particular, this profile cannot tell us whether we allocate more
memory than we free.

>  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.

Thanks.

Previous Next

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