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

Previous Next

Full log

Message #8 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 15:23:13 +0300

> From: Przemysław Alexander Kamiński
>  <przemyslaw <at> kaminski.se>
> Date: Tue, 15 Jul 2025 09:12:47 +0200
> 
> it seems there's some memory leak happening in redisplay_internal
> function.
> 
> I've noticed that over time Emacs become slower and slower. After 2-3
> hours bug is noticable. Total - as reported by OS - usage is >2Gb. GC is
> working correctly and running it manually didn't change anything. Memory
> report marks only ~50mb, and total memory on relatively fresh instance
> is ~500mb. I've noticed that at approx 3Gb I start receiving "freezes of doom".

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

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

> Can't say anything more, if there's anything else I could try to
> debug/report let me know.

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.

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?

Thanks.

Previous Next

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