10 ms·

Monterey’s memory leak and how to avoid it

105 points by llimllib 5y ago

duffyjp 5y ago
I'm on an intel iMac with Big Sur and 48GB of ram. I've had this memory leak plague my system at least half a dozen times. I just checked and I'm one notch up from "normal" on the cursor size. I tried setting it back but it's just too damn small on this 27" 5K display. I guess I'll just crash for the time being.
pwthornton 5y ago
This explains why the behavior is so inconsistently seen. I haven’t seen it on my three macs and others have had their systems crippled by it.
thebean11 5y ago
> There was no significant change in memory used by WindowServer (3.37 GB) Isn't that high for WindowServer? I haven't seen mine over 1GB.
ethbr0 5y ago
If true on causes, how did this get through QA? A new feature, that when used leaks memory, in any application that changes the cursor between pointer and something else frequently.
- dagmx 5y ago
  Memory leaks tend to be difficult to capture in most QA settings. You'd have to be running a build for significantly longer than most people run their QA test suite for, focusing on specific actions. Unless the memory leak ratcheted up memory use immediately, it's going to be hard to detect as a result.
  - josephg 5y ago
    This is why tools like valgrind are indispensable. You can run your target process through your test suite with valgrind (or apple’s Instruments) and it’ll tell you if any memory leaked. Even if it’s just a few bytes.
    - tylerhou 5y ago
      I don't know if Valgrind (or Clang msan) would catch this bug as it might not be associated with any calls to *alloc/mmap/free/etc. Seems like a kernel issue, and I don't know if Valgrind has the capability to peer that deep.
    - lordnacho 5y ago
      There's more than one way to leak memory though. One way is the classic where you get memory from an OS call, and then you lose the pointer to it. Valgrind will then correctly tell you that there's this memory that your app can no longer access. But you can also simply use more and more memory without losing track of where it is. Say you have some function that gets a new piece of memory and then stores the pointer, again and again. Such a program isn't leaking memory in the classic sense, but it's still using more and more memory. Your tool won't know that this isn't supposed to be happening. IIRC a common way to leak memory the second way is in GC'ed programs where for instance you might have a closure that owns the pointer, thus the GC when it's marking the objects does not think it needs to clean up the object at the next sweep.
      - lupire 5y ago
        That's usually called a space leak, distinguishing space-wasting program logic from explicit memory mismanagement. Users of a program generally can't distinguish space leak from memory leak, unless you inspect the heap to look for growing chains or pools of similar objects.
sa1 5y ago
I got my first (Your computer has run out of memory) warnings recently on an Intel Mac (MBP 2015), during normal laptop usage. My pointer settings are already the default. Maybe the laptop is already too old for Monterey.
- gnicholas 5y ago
  It’s possible that changing the pointer setting and changing it back could help. It is also possible that your MBP is too old to run Monterey smoothly. I’ve noticed that my 2017 MBP (base model CPU) is noticeably slower with common tasks like spotlight. I’m sure apple is optimizing for their own chips these days, and they don’t mind if this results in worse performance on Intel machines. It’ll speed up the upgrade cycle, which is good for them (and bad for us).
garblegarble 5y ago
The title incorrectly implies implies this is the only bad memory leak in Monterey (even though the author acknowledges it's not the only in an edit complaining about 'comment bombing'). While the pointer one may be the worst culprit, it's definitely not the only one - every few days I see Control Center using >3GB (once force-killed, it goes back down to 26MB). It's not a massive issue on my machine (I just check memory usage every day) but it gives a very bad impression that Apple haven't fixed it yet. I'm sure is especially challenging for non-technical users who're more likely to be on a lower-memory system and run out of memory regularly
- marcellus23 5y ago
  > it gives a very bad impression that Apple haven't fixed it yet. This suggests that it's a common or even universal problem, but are you sure that's the case? I've never seen Control Center use an inordinate amount of memory -- it may very well be a rare or unique issue. edit: I see someone else ran into it — fair enough! Still, I think it's funny how often I see "I keep running into this bug, why haven't they fixed it!" on HN, considering how software developers should know, better than anyone, how often bugs are hard-to-reproduce edge cases.
  - throwntoday 5y ago
    I've seen enough people talking about it that I don't believe it is unique. I check my activity a couple times a day, and there doesn't appear to be any correlation between use and control center randomly taking >1GB of memory. I could for instance check when all apps are closed and it's memory usage is high but then after a long day of work it's still floating around 30MB. I'm baffled at what the issue actually is but control center appears to be processing a lot more data now as all media seems to pass through it in some way.
    - marcellus23 5y ago
      Control Center is also built using SwiftUI I believe. SwiftUI still has a lot of rough edges especially on Macs, I wonder if that's the issue?
gnicholas 5y ago
I recently ran into a memory leak in Mojave (Mail was consuming 49 GB of RAM), so I finally upgraded to Monterey. The memory leak is gone, but now I’m seeing incredible CPU usage in Mail (1/2 to 3/4 of my MBP’s total resources, while Mail is idle). I called AppleCare and they said they are aware of the problem and will be fixing it in an upcoming release.
- officeplant 5y ago
  It's an improvement from Mail occasionally causing grey screens of death on M1 machines in Big Sur.
mattl 5y ago
Seeing this on latest Big Sur too.
mzs 5y ago
source: https://bugzilla.mozilla.org/show_bug.cgi?id=1735345#c18 https://bugzilla.mozilla.org/show_bug.cgi?id=1735345#c18 --- Markus Stange [:mstange] Comment 18 • 1 month ago • Edited I've filed FB9704004 about this. -[NSCursor set] appears to be leaking images, causes 70GB leak in Firefox This appears to be a regression in one of the recent macOS Monterey Betas. Two Firefox users reported a very large memory usage. We’re tracking this in https://bugzilla.mozilla.org/show_bug.cgi?id=1735345 . We have a memory report which blames the allocations on this stack: #02: _malloc_zone_malloc[/usr/lib/system/libsystem_malloc.dylib +0x1e770] #03: createImageWithSizeRenderInstructions[/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x7430] #04: -[_AXFMouseCursorGeneratorLayer _createImageForScale:color:][/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x66e0] #05: -[_AXFMouseCursorGenerator createImageForScale:][/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x5064] #06: -[_AXFMouseCursorGenerator _registerWithName:connection:isGlobal:setActive:seed:][/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x5418] #07: _AXFCursorSetAndReturnSeed[/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x70b8] #08: _AXInterfaceCursorSetAndReturnSeed[/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices +0x2d1d8] #09: -[NSCursor _reallySet][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x1e01d0] #10: -[NSCursor set][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x1e0050] Firefox calls -[NSCursor set] very frequently during mouse motions, so many leaked images might accumulate.
still_grokking 5y ago
Seeing all the comments here I'm asking myself once more how people can bear such crappy products. Especially as the products are overpriced on any reasonable scale. With a stock Linux you never see anything even close to all those catastrophes. I'm not aiming at a OS flame but honestly question how this is bearable to otherwise mostly reasonable people. Is there a true core to this Stockholm syndrome meme about Apple users? Why are people using obviously extremely broken stuff, especially as it costs at least one-third more than perfectly fine working stuff? I just don't get that. Honestly!
- lmilcin 5y ago
  I have been using Linux since last millennium and I can tell you there is no shortage of bugs. Just right now I am fighting my Fedora upgrade and Pipewire systems that are constantly reverting my custom configuration that I wrote to prevent automatically suspending audio to my external DAC. On a normal audio output it does not matter when your audio stops sending analog signal, but mine is connected over Toslink. When the signal stops the DAC on the other side also shuts down. Then when the sound gets back it takes time for it to turn on again (2s of silence + 2s of slow volume ramp up) which is extremely annoying. This happens by default after 30s of inactivity. Unfortunately, Pipewire developers seem to be having some pretty strange ideas about how to work with user configuration (basically, don't care about it). I had custom configuration and then it got overriden when they decided to move configuration from /etc to somewhere in /usr. Then I edited in /usr but it got overriden by fedora update system the next time it has been updated (I guess I could have predicted it). Then I followed documentation and edited in my $HOME/.config but apparently this also stopped working yesterday. And I just want to keep my audio working. Don't get me started on graphics or dev environment. See, no shortage of frustration there...
  - still_grokking 5y ago
    I'm also using Linux since the last millennium. I can't confirm such issues. Using Fedora means using experimental stuff. Pipewire for example is not ready for prime time, so it has obviously issues. Simple as that. But I don't say of course Linux is without bugs. Never seen any more complex software without bugs… The point is how grave those bugs are and how they could possibly pass QA. Especially Apple has a comparably simple job here as they only support officially a hand full of products which are even build by themself. And it's not only me who sees one catastrophe following the other at Apple. Just have a look at the discussion thread on the other current front page topic: https://news.ycombinator.com/item?id=29229881 https://news.ycombinator.com/item?id=29229881 To repeat my question: How do people bear that? That's what I just can't understand. Again, I'm not interested in an OS flamewar. That Apple's products are subpar is a fact at this point, and we don't need to discuss that again. (Just follow the other HN thread). The question is why people are still using this stuff and not voting with their wallet (especially as it would make their wallet more happy).
speedgoose 5y ago
Perhaps Apple should switch to a programming language with a garbage collector.
- yxhuvud 5y ago
  Apple uses Swift. Swift uses ARC which is a kind of garbage collector (the naive and eager reference counting kind).
- vlovich123 5y ago
  I can write you a memory leak in any language you want. No GC strategy can solve that as doing so is equivalent to solving the halting problem (at least that's my intuition).
  - tylerhou 5y ago
    It's not equivalent; you can tag every pointer with a special bit. Then statically you know the accessible roots at every instruction pointer value, and you can simply traverse accessible memory regions, following tagged pointers. Free all memory that is not visited. A decision problem equivalent to the halting problem might be (depending on the language): does this code free all allocated memory correctly (assuming no garbage collector)?
    - vlovich123 5y ago
      Cool. That only tells you which memory is no longer actively referenced. It does not tell you whether or not you’ve leaked memory due to stale live references.
      - tylerhou 5y ago
        But then your definition of leak is arbitrary, because who's to say that memory won't be re-accessed in the future? You're right that that problem is equivalent to the halting problem.
      - speedgoose 5y ago
dang 5y ago
Recent and related: Memory leaks are crippling my M1 MacBook Pro - https://news.ycombinator.com/item?id=29142157 https://news.ycombinator.com/item?id=29142157 - Nov 2021 (727 comments)

105 points by llimllib 5y ago

I'm on an intel iMac with Big Sur and 48GB of ram. I've had this memory leak plague my system at least half a dozen times. I just checked and I'm one notch up from "normal" on the cursor size. I tried setting it back but it's just too damn small on this 27" 5K display. I guess I'll just crash for the time being.

pwthornton 5y ago

This explains why the behavior is so inconsistently seen. I haven’t seen it on my three macs and others have had their systems crippled by it.

thebean11 5y ago

> There was no significant change in memory used by WindowServer (3.37 GB) Isn't that high for WindowServer? I haven't seen mine over 1GB.

ethbr0 5y ago

If true on causes, how did this get through QA? A new feature, that when used leaks memory, in any application that changes the cursor between pointer and something else frequently.

dagmx 5y ago
Memory leaks tend to be difficult to capture in most QA settings. You'd have to be running a build for significantly longer than most people run their QA test suite for, focusing on specific actions. Unless the memory leak ratcheted up memory use immediately, it's going to be hard to detect as a result.
- josephg 5y ago
  This is why tools like valgrind are indispensable. You can run your target process through your test suite with valgrind (or apple’s Instruments) and it’ll tell you if any memory leaked. Even if it’s just a few bytes.
  - tylerhou 5y ago
    I don't know if Valgrind (or Clang msan) would catch this bug as it might not be associated with any calls to *alloc/mmap/free/etc. Seems like a kernel issue, and I don't know if Valgrind has the capability to peer that deep.
  - lordnacho 5y ago
    There's more than one way to leak memory though. One way is the classic where you get memory from an OS call, and then you lose the pointer to it. Valgrind will then correctly tell you that there's this memory that your app can no longer access. But you can also simply use more and more memory without losing track of where it is. Say you have some function that gets a new piece of memory and then stores the pointer, again and again. Such a program isn't leaking memory in the classic sense, but it's still using more and more memory. Your tool won't know that this isn't supposed to be happening. IIRC a common way to leak memory the second way is in GC'ed programs where for instance you might have a closure that owns the pointer, thus the GC when it's marking the objects does not think it needs to clean up the object at the next sweep.
    - lupire 5y ago
      That's usually called a space leak, distinguishing space-wasting program logic from explicit memory mismanagement. Users of a program generally can't distinguish space leak from memory leak, unless you inspect the heap to look for growing chains or pools of similar objects.

sa1 5y ago

I got my first (Your computer has run out of memory) warnings recently on an Intel Mac (MBP 2015), during normal laptop usage. My pointer settings are already the default. Maybe the laptop is already too old for Monterey.

gnicholas 5y ago
It’s possible that changing the pointer setting and changing it back could help. It is also possible that your MBP is too old to run Monterey smoothly. I’ve noticed that my 2017 MBP (base model CPU) is noticeably slower with common tasks like spotlight. I’m sure apple is optimizing for their own chips these days, and they don’t mind if this results in worse performance on Intel machines. It’ll speed up the upgrade cycle, which is good for them (and bad for us).

garblegarble 5y ago

The title incorrectly implies implies this is the only bad memory leak in Monterey (even though the author acknowledges it's not the only in an edit complaining about 'comment bombing'). While the pointer one may be the worst culprit, it's definitely not the only one - every few days I see Control Center using >3GB (once force-killed, it goes back down to 26MB). It's not a massive issue on my machine (I just check memory usage every day) but it gives a very bad impression that Apple haven't fixed it yet. I'm sure is especially challenging for non-technical users who're more likely to be on a lower-memory system and run out of memory regularly

marcellus23 5y ago
> it gives a very bad impression that Apple haven't fixed it yet. This suggests that it's a common or even universal problem, but are you sure that's the case? I've never seen Control Center use an inordinate amount of memory -- it may very well be a rare or unique issue. edit: I see someone else ran into it — fair enough! Still, I think it's funny how often I see "I keep running into this bug, why haven't they fixed it!" on HN, considering how software developers should know, better than anyone, how often bugs are hard-to-reproduce edge cases.
- throwntoday 5y ago
  I've seen enough people talking about it that I don't believe it is unique. I check my activity a couple times a day, and there doesn't appear to be any correlation between use and control center randomly taking >1GB of memory. I could for instance check when all apps are closed and it's memory usage is high but then after a long day of work it's still floating around 30MB. I'm baffled at what the issue actually is but control center appears to be processing a lot more data now as all media seems to pass through it in some way.
  - marcellus23 5y ago
    Control Center is also built using SwiftUI I believe. SwiftUI still has a lot of rough edges especially on Macs, I wonder if that's the issue?

gnicholas 5y ago

I recently ran into a memory leak in Mojave (Mail was consuming 49 GB of RAM), so I finally upgraded to Monterey. The memory leak is gone, but now I’m seeing incredible CPU usage in Mail (1/2 to 3/4 of my MBP’s total resources, while Mail is idle). I called AppleCare and they said they are aware of the problem and will be fixing it in an upcoming release.

officeplant 5y ago
It's an improvement from Mail occasionally causing grey screens of death on M1 machines in Big Sur.

mattl 5y ago

Seeing this on latest Big Sur too.

mzs 5y ago

source: https://bugzilla.mozilla.org/show_bug.cgi?id=1735345#c18 https://bugzilla.mozilla.org/show_bug.cgi?id=1735345#c18 --- Markus Stange [:mstange] Comment 18 • 1 month ago • Edited I've filed FB9704004 about this. -[NSCursor set] appears to be leaking images, causes 70GB leak in Firefox This appears to be a regression in one of the recent macOS Monterey Betas. Two Firefox users reported a very large memory usage. We’re tracking this in https://bugzilla.mozilla.org/show_bug.cgi?id=1735345 . We have a memory report which blames the allocations on this stack: #02: _malloc_zone_malloc[/usr/lib/system/libsystem_malloc.dylib +0x1e770] #03: createImageWithSizeRenderInstructions[/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x7430] #04: -[_AXFMouseCursorGeneratorLayer _createImageForScale:color:][/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x66e0] #05: -[_AXFMouseCursorGenerator createImageForScale:][/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x5064] #06: -[_AXFMouseCursorGenerator _registerWithName:connection:isGlobal:setActive:seed:][/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x5418] #07: _AXFCursorSetAndReturnSeed[/System/Library/PrivateFrameworks/AccessibilitySupport.framework/Versions/A/Frameworks/AccessibilityFoundation.framework/Versions/A/AccessibilityFoundation +0x70b8] #08: _AXInterfaceCursorSetAndReturnSeed[/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices +0x2d1d8] #09: -[NSCursor _reallySet][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x1e01d0] #10: -[NSCursor set][/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x1e0050] Firefox calls -[NSCursor set] very frequently during mouse motions, so many leaked images might accumulate.

still_grokking 5y ago

Seeing all the comments here I'm asking myself once more how people can bear such crappy products. Especially as the products are overpriced on any reasonable scale. With a stock Linux you never see anything even close to all those catastrophes. I'm not aiming at a OS flame but honestly question how this is bearable to otherwise mostly reasonable people. Is there a true core to this Stockholm syndrome meme about Apple users? Why are people using obviously extremely broken stuff, especially as it costs at least one-third more than perfectly fine working stuff? I just don't get that. Honestly!

lmilcin 5y ago
I have been using Linux since last millennium and I can tell you there is no shortage of bugs. Just right now I am fighting my Fedora upgrade and Pipewire systems that are constantly reverting my custom configuration that I wrote to prevent automatically suspending audio to my external DAC. On a normal audio output it does not matter when your audio stops sending analog signal, but mine is connected over Toslink. When the signal stops the DAC on the other side also shuts down. Then when the sound gets back it takes time for it to turn on again (2s of silence + 2s of slow volume ramp up) which is extremely annoying. This happens by default after 30s of inactivity. Unfortunately, Pipewire developers seem to be having some pretty strange ideas about how to work with user configuration (basically, don't care about it). I had custom configuration and then it got overriden when they decided to move configuration from /etc to somewhere in /usr. Then I edited in /usr but it got overriden by fedora update system the next time it has been updated (I guess I could have predicted it). Then I followed documentation and edited in my $HOME/.config but apparently this also stopped working yesterday. And I just want to keep my audio working. Don't get me started on graphics or dev environment. See, no shortage of frustration there...
- still_grokking 5y ago
  I'm also using Linux since the last millennium. I can't confirm such issues. Using Fedora means using experimental stuff. Pipewire for example is not ready for prime time, so it has obviously issues. Simple as that. But I don't say of course Linux is without bugs. Never seen any more complex software without bugs… The point is how grave those bugs are and how they could possibly pass QA. Especially Apple has a comparably simple job here as they only support officially a hand full of products which are even build by themself. And it's not only me who sees one catastrophe following the other at Apple. Just have a look at the discussion thread on the other current front page topic: https://news.ycombinator.com/item?id=29229881 https://news.ycombinator.com/item?id=29229881 To repeat my question: How do people bear that? That's what I just can't understand. Again, I'm not interested in an OS flamewar. That Apple's products are subpar is a fact at this point, and we don't need to discuss that again. (Just follow the other HN thread). The question is why people are still using this stuff and not voting with their wallet (especially as it would make their wallet more happy).

speedgoose 5y ago

Perhaps Apple should switch to a programming language with a garbage collector.

yxhuvud 5y ago
Apple uses Swift. Swift uses ARC which is a kind of garbage collector (the naive and eager reference counting kind).
vlovich123 5y ago
I can write you a memory leak in any language you want. No GC strategy can solve that as doing so is equivalent to solving the halting problem (at least that's my intuition).
- tylerhou 5y ago
  It's not equivalent; you can tag every pointer with a special bit. Then statically you know the accessible roots at every instruction pointer value, and you can simply traverse accessible memory regions, following tagged pointers. Free all memory that is not visited. A decision problem equivalent to the halting problem might be (depending on the language): does this code free all allocated memory correctly (assuming no garbage collector)?
  - vlovich123 5y ago
    Cool. That only tells you which memory is no longer actively referenced. It does not tell you whether or not you’ve leaked memory due to stale live references.
    - tylerhou 5y ago
      But then your definition of leak is arbitrary, because who's to say that memory won't be re-accessed in the future? You're right that that problem is equivalent to the halting problem.
    - speedgoose 5y ago

dang 5y ago

Recent and related: Memory leaks are crippling my M1 MacBook Pro - https://news.ycombinator.com/item?id=29142157 https://news.ycombinator.com/item?id=29142157 - Nov 2021 (727 comments)