Monterey’s memory leak and how to avoid it

You will no doubt have heard of the claimed memory leak in macOS Monterey 12.0.1. Thanks to the work of the engineers at Mozilla, its cause has now been identified, and I’m very grateful to fujimidai1 who has pointed this out to me. This article explains how it occurs, and how you can prevent it from happening on your Mac.

Soon after the release of macOS 12.0.1, reports appeared that some apps, notably Firefox, could suffer large and progressive memory leaks until they took 70 GB or more of app memory, and the Mac simply ran out. At first this appeared confined to certain apps, including Firefox, Microsoft Word, and even Safari. What was perhaps most surprising was that some users were severely affected, but most users weren’t affected at all and could use the same apps for days without any significant change occurring in their memory use. Neither was there any evidence of kernel or Mach zone memory leaks.

The cause has now been isolated to a single group of settings in one preference pane, Accessibility. All Macs which appear to suffer this leak are using custom pointer controls in the Pointer tab of the Display, specifically a larger than normal Pointer size and custom outline and fill colours. The latter two items are one of the new features in Monterey, and have proved popular with users. (Note that this interface device is termed a pointer, not a cursor, a common error.)

The leak appears to occur when the pointer type changes, for example from a standard arrow to an I-beam for the insertion of text. What is most likely is that, when the pointer has been customised using the settings in that pane, the memory used by the previous pointer isn’t freed following a change in pointer type. Apps which feature many and frequent changes in pointer type, such as browsers, therefore leak memory more quickly than those that change the pointer type less often. However, every app with an interface in which the pointer can change type will leak until this bug is fixed in Monterey.


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.

It’s extremely easy to test this using Activity Monitor. When I had loaded my main working apps, I set a custom pointer in Accessibility, and noted the memory used by main apps before using them. At that stage, app memory was 16.12 GB, with Safari, for example, taking 108 MB. After a few minutes of use with the custom pointer, app memory had risen to 17.82 GB, with Safari using 623 MB, the highest I have ever seen on this Mac.

Notable rises included:

  • Postbox from 442 to 951 MB,
  • Safari from 108 to 623 MB,
  • Tweetbot from 103 to 196 MB.

There was no significant change in memory used by WindowServer (3.37 GB), the Dock, or CoreSpotlightService, and little change in the Finder.

Hopefully Apple will fix this leak in 12.1, currently in beta-testing.


I regret that someone is ‘comment-bombing’ this article by posting multiple links to it claiming that there are other memory leaks in 12.0.1. There may well be, but unless you tell others where those leaks are and how they can avoid them, all you’re doing is creating FUD. Best get down to some work finding out where those leaks are then, rather than spreading more unhelpful rumour.

There’s a new article summarising this and another three memory leaks in 12.0.1 which you may wish to read.