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
Rudolf Adamkovič <rudolf <at> adamkovic.org> 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č <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.