Last week I published an article in which I explained what was then the prominent memory leak which had been demonstrated in macOS Monterey 12.0.1. Several informed me that there were others, and thanks to the investigative work of those readers, I can now describe a total of four, three of which I can reproduce here, and one which I can’t. This article summarises them, and how to avoid becoming victim to them. My previous article provides a more detailed account of what memory leaks are.

Coloured pointers

This memory leak can rapidly become severe, but is only triggered by the use of a feature which is new to Monterey, colouring the pointer. When that feature is turned off, it shouldn’t affect your Mac.

If you open the custom pointer controls in the Pointer tab of the Display item in the Accessibility pane, and set the pointer to be larger than normal using the Pointer size control, and set custom outline and fill colours, each time that your pointer changes type, such as from an arrow to an I-beam, the memory allocated for the previous type isn’t freed, but leaks. This appears to be triggered specifically by the custom colour settings, but the size of the leak grows as the pointer size is increased.

Leaked memory remains within that allocated to the app whose active window is underneath the pointer at the time that its type changes. This makes the leak hard to track, as it can and will effect any app with a human interface, from the App Store to Xcode.

The workaround is simple: open the Accessibility pane, select Display at the left, then the Pointer tab. Set the Pointer size there to Normal, and click on the Reset button to undo any colour customisation. Once you have done that, quit all open apps and at least log out as the user. To be certain, a restart is recommended. No further memory leak from this cause should then occur. Several users report that changing only the pointer size control, without setting a custom colour, is safe, and doesn’t result in any memory leak.

This leak has been reported to Apple by the Mozilla engineers who discovered it. It appears 100% reproducible on Intel and M1 models, and seems likely to be fixed in macOS 12.1. I’m very grateful to fujimidai1 for telling me about it.

Finder File/Find

This memory leak occurs when using the Find command to search for files in Finder, and can become very large with repeated Find operations. It doesn’t affect normal Spotlight search, nor search using third-party Spotlight tools such as HoudahSpot or Find Any File (FAF).

To see this, open a new Finder window and convert it to Find using the Find command in the Finder’s File menu. Each time that you type characters into its search box, triggering a search, Finder memory use will increase, but won’t return to normal even when that window is closed. The amount of memory leaked with each search varies, and appears to be related to the number of hits returned. In some cases, the Finder’s memory can rise irreversibly by hundreds of MB with a single search.

The most likely cause of this leak is that at least part of the data returned in the previous search isn’t freed when the next search is started.

Because leaked memory is from the Finder, the only way to recover it is to force the Finder to be relaunched using the Force Quit dialog (Command-Option-Escape). There’s no direct workaround, although other methods of searching for files appear unaffected and should be used instead, particularly when multiple searches are anticipated.

This leak has now been reported to Apple by bwillius (see comments below), and I haven’t seen any other analysis of it. It appears 100% reproducible on Intel and M1 models. I’m very grateful to Since1985 for telling me about it, to bwillius for both confirming and reporting it.

Control Centre

Many users have reported instances of Control Centre apparently using extremely large amounts of memory, often more than 20 GB, but my testing suggests that any leak in Control Centre is small and slow. Extended testing using the Play control coupled with AirPlay failed to demonstrate any leak at all, with memory used remaining below 85 MB in a period of over an hour. However, intensive use of the Display control to change Display Profile did result in a small leak of about 10 MB with each change. The cause of any more substantial leak is thus obscure, and may relate to unidentified interactions with specific controls in Control Centre.

To attempt to replicate this, open the Control Centre and repeatedly access its individual controls. Memory use normally increases when one of the controls is being accessed, then falls again when the window is closed. Depending on the control used, memory used may not return completely to its previous level, with growth ranging from 2 to 10 MB on each occasion.

In light and infrequent use of the Control Centre, users shouldn’t notice any leak. If it does occur, the only solution is to log out and back in. There’s no workaround, other than limiting use of these controls.

I don’t know whether this leak has been reported to Apple, nor have I seen any other analysis of it. It appears 100% reproducible on Intel and M1 models, but only in small amounts. I’m very grateful to The_Lucifer for telling me about this potential memory leak.

avconferenced (FaceTime) (not reproduced)

Some users have reported the avconferenced process, used in FaceTime, can use tens of GB of memory during long FaceTime calls. Attempts to reproduce this here have failed to reveal any evidence of a leak or of excessive memory use, though, despite using features new to Monterey including Portrait and microphone modes. The cause of any leak is thus obscure.

During testing on an M1 Pro (MacBook Pro 2021 16-inch), avconferenced typically used around 270 MB when both Portrait Mode and Microphone Isolation were active. This fell to 250 MB or less when those features were disabled, again without any evidence of a leak. However, after quitting FaceTime, avconferenced continued to use 108 MB instead of falling to normal, although total memory use of the M1 Pro remained tiny, below 7 GB of 32 GB installed.

I’m very grateful to The_Lucifer for telling me about this potential memory leak. Further testing and information is required.

What is a memory leak?

All software has to allocate memory to contain data. The data might be read from a file, or created by converting other data, etc., and when that allocated memory is no longer required, it has to be freed and returned for reuse. In a memory leak that return doesn’t happen, and instead of the memory being freed it’s left still in use. Over time, that accumulates, until no more memory can be allocated from that pool. At that point, the leaking app comes to a grinding halt.

The first indication that there might be a memory leak somewhere is normally a noticeable fall in performance. Actions which are normally instant result in a pause, sometimes long enough to display the spinning beachball. Kernel memory leaks may remain hidden, though, until they cause a kernel panic. The ensuing panic log may be the only clue as to what has happened.

App memory leaks in user space are easily identified using Activity Monitor or a substitute which displays accurate figures for app memory use. An app which might start up using a few hundred MB of memory grows steadily with time and usage until it reaches many GB, by which stage the app’s performance normally suffers as most of that has to be virtual. This is likely to push overall memory use into the red zone.

For the user, there’s one good way to live with app memory leaks: quitting the app should return all the memory that was allocated to it. If a leaking app has reached 20 GB of memory used, save your work, quit the app, and open it again. While this isn’t convenient, it does allow you to continue working, as does switching to another app which can do the same job. Always let the app developer know, so that they can discover the cause and fix it.

If you suspect there’s a memory leak anywhere on your Mac, use Activity Monitor to watch what happens. Opening windows and performing other actions which require memory should normally result in the memory being used by that app rising, and that’s only to be expected. What characterises a leak is that, when that window is closed or the action completed, the app’s memory requirement doesn’t fall, at least not to its previous level. Over time, the app’s memory grows until it becomes pathologically large. Make careful and detailed notes of what happened, together with memory use figures from Activity Monitor, so you can report the problem.

What to do when you find one

Although I’m always interested to hear of significant memory leaks in macOS and its bundled apps, I can’t do anything about them. If you’re confident that the leak is occurring in macOS or any other Apple software, please report it to Apple using its Feedback form. Developers can provide more information through the Developer Feedback reporting system, using Feedback Assistant.

Before reporting the leak, do a bit of detective work to discover exactly how you can trigger the leak, and be sure to provide Apple with full instructions as to how to do that. The best way for an engineer to discover the cause of a leak, and to fix it, is when they can reproduce the leak themselves. Consider carefully the possible role of third-party apps and software. If another product is involved, please also report it to its developer so that they too can look at it.

Why is Monterey so prone to memory leaks?

I don’t think it is. Small memory leaks aren’t uncommon, particularly in new major versions of macOS, although leaks as large as the first two detailed above are unusual in macOS. Neither should, of course, have appeared in a beta-release, as they should have been detected and rectified by quality assurance processes. However, neither (particularly the coloured pointer leak) is likely to have been well-tested during the beta phase. They stand out in 12.0.1 because, unlike major new versions in previous years, there are relatively few major bugs in Monterey, indeed there are many bugs which have been fixed.

Updated 2250 UTC 22 November 2021 with additional information about the Control Center leak.