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: Wed, 16 Jul 2025 08:49:47 +0200

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

Yesterday I was able to hookup MacOS' Instruments.app to build Emacs. Took some effort to figure out, but once done it was rather easy. I'll make a short note and publish the steps.

Findings:
- There are multiple leaks, but most of them are very small in total they accrue ~1m per minute
- The total run was ~2.5m (it slows Emacs down so it's hard to use it all the time) and I cut off initialization leaks (~1.5m, some related to Toolbar initialization)
- I'm attaching two text files (not sure if it won't bounce)
  - First one are few example of complex loops - they seem to hit lisp_allign_malloc which seems to be related to MacOS-specific code
  - Second one are root loops.

I found few other weird things, e.g. it seems that opening a single midsize buffer processed approx. 2GiB of memory and that a single symbol allocates 1KiB of memory, but I don't think it's the proper thread to discuss further.

Of course there's more but sharing in text form is very difficult. In case someone wants to reproduce by themselves, what it takes is to add task/debug entitlements (see attached debug.plist) through signing. I had to remove com.apple.FinderInfo from emacs-plus build, not sure where it came from. Build was with debug symbols for easier debugging. Commands I used:

$ xattr -d com.apple.FinderInfo /path/to/Emacs.app
$ codesign -s - -v -f --entitlements /path/to/debug.plist /path/to/Emacs.app

After that I started Instruments.app set app bundle for analysis and launched from there.

Lot of interesting info, but slows down considerably when constantly probed. I'm somewhat stoked about this because I'm optimization freak and Emacs speed on MacOS wasn't something great - it usually deteriorates after hours - I blamed fancy packages like Marginalia, but if it leaks drops on small allocations it would make sense why it accelerated the process.

Best,
Przemysław Alexander Kamiński

[leaks2.txt (text/plain, attachment)]

[leaks1.txt (text/plain, attachment)]

[debug.plist (text/plain, attachment)]

Previous Next

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