Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS)

From: Rudolf Adamkovič <[email-masked]>
Date: Mon, 21 Jul 2025 21:58:24 +0200

Rudolf Adamkovič <[email-masked]> writes:

>      (dotimes (x 1000)
>        (let ((frame (make-frame-command)))
>          (sleep-for 0.01)
>          (delete-frame frame)))

Okay, while on it....

I did this for 100 frames with Instruments attached, after suffering
through Apple signing nonsense.  I found that Emacs leaks memory like
there was no tomorrow (401 thousand leaks), but the leaks were too small
to explain 5.22 GB of RAM used, per the Activity Monitor.  So, I tried
the Allocation instruments, in addition to Leaks, and indeed, and the
code above resulted in 1098 allocations of 4.72 MB, totaling ~5.18 GB,
and they are all like these:

1 0x4432b0000 VM: IOSurface 01:22.610.316 • 4,72 MiB Emacs -[EmacsLayer getContext]
2 0x442df8000 VM: IOSurface 01:22.575.202 • 4,72 MiB Emacs -[EmacsLayer getContext]
3 0x442940000 VM: IOSurface 01:22.509.260 • 4,72 MiB Emacs -[EmacsLayer getContext]
4 0x442488000 VM: IOSurface 01:22.471.821 • 4,72 MiB Emacs -[EmacsLayer getContext]
5 0x441fd0000 VM: IOSurface 01:22.422.630 • 4,72 MiB Emacs -[EmacsLayer getContext]

There are other allocations, of course, but these explain most of the
memory pressure.  The memory stays allocated even after waiting for 15
minutes, doing nothing.

Rudy
-- 
"The introduction of suitable abstractions is our only mental aid to
organize and master complexity."
--- Edsger Wybe Dijkstra, 1930-2002

Rudolf Adamkovič <[email-masked]> [he/him]
http://adamkovic.org