3/19/2023 0 Comments Easyres macAfter finishing up a moderately long facetime call, callservicesd ends up using multiple gigabytes of ram (it grows slowly over the course of a call). I’ve been able to reproduce one really easily. If Big Sur gets that wrong, then that’s a terminology bug.Įh, there’s a lot of other memory leaks in Monterey. The cursor is controlled by the arrow or cursor keys, not by moving the mouse or trackpad. So if you using Big Sur or earlier, macOS doesn’t offer the feature which is responsible, and you shouldn’t see any memory leak.įinally, Apple’s long-established terminology is clear: the pointer floats over the display, controlled by the mouse or trackpad a cursor is quite different, and is the term for the insertion point, typically in text, which is bound within some views, placed there by clicking the pointer at that insertion point. The new feature introduced is changing the outline and fill colours of the pointer, and that’s clearly what has caused the memory leak. The feature to change the size of the pointer has been available, and has been well-used, before Monterey. However, this memory leak is new with Monterey, and hasn’t been observed in Big Sur or earlier. Yes I did, as it was part of the Mozilla description of the bug. There’s a new article summarising this and another three memory leaks in 12.0.1 which you may wish to read. Best get down to some work finding out where those leaks are then, rather than spreading more unhelpful rumour. 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. ![]() 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. Hopefully Apple will fix this leak in 12.1, currently in beta-testing. There was no significant change in memory used by WindowServer (3.37 GB), the Dock, or CoreSpotlightService, and little change in the Finder. 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. At that stage, app memory was 16.12 GB, with Safari, for example, taking 108 MB. 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. It’s extremely easy to test this using Activity Monitor. No further memory leak from this cause should then occur. Once you have done that, quit all open apps and at least log out as the user. Set the Pointer size there to Normal, and click on the Reset button to undo any colour customisation. The workaround is simple: open the Accessibility pane, select Display at the left, then the Pointer tab. However, every app with an interface in which the pointer can change type will leak until this bug is fixed in Monterey. 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. 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. ![]() ![]() 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. (Note that this interface device is termed a pointer, not a cursor, a common error.) The latter two items are one of the new features in Monterey, and have proved popular with users. 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 cause has now been isolated to a single group of settings in one preference pane, Accessibility. Neither was there any evidence of kernel or Mach zone memory leaks. 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. At first this appeared confined to certain apps, including Firefox, Microsoft Word, and even Safari. 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. This article explains how it occurs, and how you can prevent it from happening on your Mac. 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. You will no doubt have heard of the claimed memory leak in macOS Monterey 12.0.1.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |