Wow, ok. I only added 3 videos which takes less than 1gb per each and yet, FCPX just crashed with memory leak issue. I guess they still didnt fix it after all.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Still experiencing memory leak with Monterey 12.5
- Thread starter sunny5
- Start date
- Sort by reaction score
Wow, ok. I only added 3 videos which takes less than 1gb per each and yet, FCPX just crashed with memory leak issue. I guess they still didnt fix it after all.
It might be the program and not Monterey.
I have been running 12.5 for a week and, for my usage, I find no memory leaks remaining. I had a lot of them upon release and it's gotten better with newer maintenance releases and I'm ready to update some of my other systems to Monterey. There's one other major network bug that seems to have been fixed by either 12.4 or 12.5 as I haven't run into it in over a month.
If you exit FCP, does the system reclaim the virtual memory?
I have been running 12.5 for a week and, for my usage, I find no memory leaks remaining. I had a lot of them upon release and it's gotten better with newer maintenance releases and I'm ready to update some of my other systems to Monterey. There's one other major network bug that seems to have been fixed by either 12.4 or 12.5 as I haven't run into it in over a month.
If you exit FCP, does the system reclaim the virtual memory?
Monterey introduced many memory leaks - I don't think that's a controversial statement. I think that they backported them to Big Sur as well.
I do think that the biggest problems are fixed now, though. Which is why I've upgraded most of my systems to Monterey. I have one that I can't upgrade officially and may just leave that one at Big Sur.
This happens regularly with new macOS versions. Which is why I usually wait a long time before upgrading.
I still have the nasty Window Server using 3GB when connected to dual 4K displays, it's insane. I have to reboot after half a day of using clamshell mode lol.
New operating systems usually add more bugs.
Ventura seems to be a mess right now based on comments in the Ventura forum.
I'm running dual 4k displays and my system is using 700 GB of RAM. The system has been up for a couple of days and I haven't had excessive RAM problems since upgrading from Big Sur a few weeks ago. I think that most of these bugs are resolved but I still see an odd case here and there.
It's really crazy the amount of memory related bugs ever since macOS Monterey came out. I always do a daily reboot these days..
Here, a thread I made there asking about this very issue was mainly focused on how much stable it was.
These ;programs haven't been update in over 2 years ago and even older! I say Rosetta with old programs will ALWAYS have memory issues! Olds apps should not be used anymore because Rosetta was crutch to get programmers to update their program to least Universal, that's a simple to with modern Macs!
I didn't happen to experience a memory leak on 12.5, yet it was a disaster battery-wise (M1 MBA). I'm back to 12.1. There's a Finder search memory leak on 12.1 but having known that I just use Spotlight instead. It's worth it to me. I'd rather give up Finder search than have the battery drain.
Why do you constantly butt into threads to blame Rosetta for memory use issues, even when the person reporting a problem hasn't mentioned using x86 software? You don't ever offer an informed, useful perspective, it's just knee-jerk blame.
Here, the OP posted a screenshot showing Final Cut Pro (an Apple application which is 100% for sure native) using over 100GB of application memory. You think that might be their problem?
But the entire idea that Rosetta causes horrible memory overuse is dumb and you should just stop pushing it so hard. The common case for Rosetta is that the x86 binary gets translated to Arm code and cached, so that subsequent launches of that same program don't even have the temporary memory or CPU overhead of running the translation.
I have two 5ks and a 4k connected to my MBP with lid open, so four screens. Window Server takes up like 5gb ram and 30% CPU almost always lol
That's... insane. If I have my iPad Pro connected via Sidecar it will go up to 3.80GB that's the maximum I have ever seen..
I don't know what you're doing but I've never seen that much RAM used up on multimonitor systems, even with discrete GPUs. I don't know if the programs that you're running take up that much space (how would that be possible?). It does sound like a memory leak. I assume that you got 64 GB of RAM. I'm glad I got 32 GB of RAM just to deal with the VM leaks early on. I had to reboot daily for a while and then I only had to reboot every ten days or so and I don't have to reboot at all now. If I got the 16 GB model, I would have had to reboot more often.
Hopefully you windowserver guys can get Apple to fix this bug.
I used to chat with an engineer regularly about economics and politics. When he was done, he would always say that he had to go add some more bugs. He had a good sense of humor as a lot of engineers don't like to admit that there are bugs in their software - they usually like to blame the end-user. The reason is the reward system - you get paid for adding features and fixing bugs detracted from writing more features.
One saying that I like is that software is broken if it isn't tested. I have seen large features where there were a handful of tests. It's often interesting trying out the features when you know that tests are minimal. Basically just about everything breaks and you ask how could something write something so fragile?
There should be process in place so that this doesn't happen but you have the pressure of schedules and rewards and it gets through.
I'm a bit surprised that Apple doesn't have tools to diagnose memory leaks that can be made available to customers. We call this Serviceability Engineering and I used to have that job. The job entailed building tools that made it easier to diagnose problems in the field. One example of this would be to write a crash dump analyzer that can diagnose problems based on the stack trace or that would provide a summary form of things that engineers want to quickly look at.
There are commercial tools to sniff for memory leaks but they're usually licensed for development organizations. It would be nice if Apple could engineer tools into macOS to do allocation and free and then analyze the calls to see where memory is leaking by the customer turning on a debug model which generates trace output that could be sent back to Apple for analysis.
That was also my former job at another company. It works better for an outright immediate crash caused by (for example) an invalid pointer reference than a gradual problem like a memory leak. There are ways an iOS or MacOS developer can have *crash* info automatically sent, provided the customer opts in.
By contrast a memory or resource leak leak is more gradual. Anyone can take a spindump of a hung or deranged process using Activity Monitor, but interpreting that generally requires source code access and a deep internal understanding of the application. Such people are hard to come by and typically would be working in new product development, not support. Companies often view the support org. as a cost center whereas product development is a profit center. It is rare to have even a tier-3 support person with source code access, deep internals knowledge and ability to debug customer problems at the source level.
For app developers with source code access, Apple has various ways to debug a memory leak. That is covered in various WWDC presentations. But the emphasis is on a developer locally debugging their own application, not remotely troubleshooting a deployed app. The common approach is problems in the field require the customer to develop a packaged procedural problem replication, send that to Apple, then they will examine it. But there is a class of problems that are not crashes, cannot be replicated, but still require support.
Xcode can use a facility called "instruments" which a developer with source code access can embed in the app to track or log parameters. In theory they can build a stand-alone instrument package which would be sent to a customer to gather debug info, but I've never heard of any FCP customer who had that done.
In the OP case, it was FCP which often uses 3rd-party plugins, often multiple plugins. Prior to the FxPlug 4 framework, those ran "in process" or within the FCP address space. Any bug in any plugin could destabilize or crash FCP. The new FxPlug 4 framework allows plugin developers to modify their code to run "out of process" and communicate with FCP via an XPC. In theory that should make the plugin ecosystem more stable. However under FxPlug 4 the developer assumes additional responsibilities about multi-thread synchronization.
I have never seen any white paper or WWDC talk about the procedure for debugging a stability problem in a deployed host app and multiple plugins, where no one person has access to all the source code (or even debug symbols). Considering how pervasive application-specific plugins are, you'd think there would be more info on that.
Obviously the ideal approach (if achievable) is for the customer to find a reproducible procedure and small, portable data set which causes the problem. But if this requires 3rd-party multiple plugins it can devolve into a finger-pointing situation. For a customer who encounters a serious non-crash problem which involves multiple 3rd-party plugins and is both intermittent and impossible to reproduce, they can try to replicate it without the plugins. If that's not possible it's a difficult situation.
I typically have multiple windows open on all 4 screens at once, multiple Outlook Teams, Safari, Chrome, Signal, Spotify, others always up. Window Server anyway from 1.5 to 5 GB of Ram used depending on how long I go between reboots. I typically reboot daily in the morning because why not, its fast enough, but sometimes its up all weekend.
I just rebooted, launched all my stuff and put my windows where I want them. Ram is 'low' but CPU is pretty high.
I just rebooted, launched all my stuff and put my windows where I want them. Ram is 'low' but CPU is pretty high.