swift-frontend memory usage

I think I've found a memory leak with GeometryReader. The memory footprint of swift-frontend grows 50gb> with this single line

I have detailed the issue here: https://github.com/Func-Main/swiftui-memory-bug

Is anyone able to confirm? I don't think this is an issue related to the purely to the .aspectRatio modifier, but rather GeometryReader in general.

This image was after 30 seconds

  • 50gb?

  • After 1 minute of testing I saw the process list 42gb

  • I encountered the same thing🥲

Replies

Hi, go ahead and report this on Feedback Assistant and attach the link to your GitHub repo. If the Swift team is able to reproduce it, they’ll try to fix it.

  • Thanks, I have just done that

  • Any references of the bug report to show here?

  • Oct 2, 2021 at 5:29 PM – FB9672770

    Submitted 24 days ago. No response.

I actually think I’m running into a few different situations where Xcode 13 memory with SourekitControl and Swift-frontend is spiralling. I’ll try and document a few other situations when they arise. The above issue occurs on a 2018 MacBook Pro and a fresh setup m1 MacBook Air (which I initially bought to try and brute force the problem away)

I started learning Swift today ( M1 MacBook Air 16gb ) and was very surprised to get a pop-up window asking me to kill some app to get some RAM back. Checked in the Activity Monitor and had swift-frontend at apx. 54 GB memory. Super super simple project, just laying out some UI elements. Quit Xcode and reopened the project, clicked Resume in the Canvas and looked how swift-frontend start eating RAM again . After 3 min or so the Preview still didn't launch.

Closed Xcode again and just opened the project and did nothing while writing this post, after a few minutes the process was over 50 GB.

Using Source Control as well ( GitHub ) in case its relevant. Attaching a capture from the Activity Monitor and one from the project.

  • If you can, feel free to upload your project and I can see if it also happens on my machine. These kind of simple examples should be submitted through the Feedback Assistant as I think we're dealing with an Xcode problem.

  • Here it is: https://github.com/enderbd/war-challenge.git . Also submitted through the Feedback Assistant. In my case I had at some point two swift-frontend processes in memory, totalling almost 100GB.

  • @bogdan_d Can you send me your feedback ID so I can reference it? Mine is FB9672770

I had the same issue and had to downgrade Xcode to 12.5.1 and the issue is gone. First I tried removing some code, including GeometryReader to avoid the problem, but it did not work. Tried other things such as restart Xcode, mac, launching other projects, cleaning derived data, cleaning up space for swap files etc. Nothing worked.

With 12.5.1, there is not even one single process called swift-frontend, all views are rendered well in Canvas. I'd love to hear a possible solution as I would need to build for iOS15 eventually.

  • Good to know downgrading Xcode is a solution for now. I only started having this problem in Xcode 13 RC so I think something is up... Although I'm surprised if it's as bad as I've experienced more people aren't talking.

Add a Comment

Following on from @alpsoy suggestion that this bug isn't present in Xcode 12.5.1 I've recreated the bug project. I can confirm that on Xcode 12.5.1 neither SourceKitService nor swift-frontend show the same memory bug.

https://github.com/Func-Main/BugTester12

Haas anyone confirmed if this is an issue on Monterey? Maybe that could help...

  • I am using Big Sur 11.6 on my 2018 macbook pro with 16g ram. And I have this problem too. I suspect that it's something related to wrong type declaration. In my last mini project, I declared the wrong type and when it compiled the code. The memory usage jumped to 20g, 30g, 40g, ..g very quickly. Both the swift-frontend and SourcekitService. I correted the type and then I had to reboot the mac to fix it. Sometimes Spotlight is taking up 100% cpu while I was just using xcode.For my current project based on the mini project I mentioned above. I created an array of objects with custom type(1000 of star coordinates). SourcekitService and swift-frontend take 40g each, and another swift-frontend thread takes up 29g of ram. The project can be complied and run but I have to wait 4 -5 minutes. If I create an empty array and append them one by one in a loop, the compile time is almost instant without memory problem. update: when I try to get the custom type array count. The problem also happens. https://imgur.com/a/8EMDTSM

  • I was wrong about the fast build time. When I cleared the build cache, it also takes 4-5 minutes to build with about 80G memory usage.

  • This issue is still happening on Monterey, and Xcode 13.1

Does Xcode 13.1 RC help to fix the issue?

  • I will test tomorrow. There’s been no activity on our feedback assistant requests so I doubt it

  •  Xcode 13.1 RC doesn't not fix this issue.

  • No, if anything it's gotten worse.

Add a Comment

This doesn't seem to be related to a macOS release (issue happens also on Big Sur). Some parsing mechanism is getting in some deadlock populating the same process if unresponsive. I've filed an own bug report. Sharing the feedback report reference will not help here. At least, my report was identified as critical and I've got almost immediate processing response. I've requested a possible workaround to help out faster (than a XCode bug fix).

The issue appeared with XCode 13 official release. Probably, the last XCode 13 Beta was still fine.

  • It looks like this issue was generally introduced with Xcode 13. On my side the issue was latent in my project as one of my units didn't have to build with Xcode 13. As soon as the build folder was cleaned, the issue happened. I also have to release for iOS15, but can't. So far no workaround is available or communicated. Should one have a workaround, please go ahead.

  • Sorry Jumbo - I've literally abandoned Xcode 13 until this issue is resolved.

Add a Comment

I've tried  Xcode 13.1 RC and I confirm this bug is still present. Only option for me to reliably develop SwiftUI at the moment is to use Xcode 12. I tried the latest Xcode 13 Beta before GM and this issue was present.

This bug also makes the entire system unresponsive, as it thrashes to disk/swap. My SSD will read/write at 900+ MB/s.

This bug will put a ton of wear and tear on our SSDs...

Xcode 13.2 beta (13C5066c) still has this issue!

I've installed the latest official release (13.1) to fix this issue that I faced on all my development units - the update took many hours (all night and longer) on my iMac 24'' M1 2021 (similar on MacBook Air M1 2020) and... the issue is still there... No response from Apple/Xcode development team - that's so disappointing. Such a massive and obvious show stopper should have grabbed more attention from them, but they just release new betas on and on without any solution nor at least "we are working on it" or similar response here.

  • In the same boat. I tried 13.2 beta 1 and the issue still happens.

Add a Comment

Hey! I experienced a similar problem too. The swift-frontend and SourceKitService processes were overloading memory incrementally. I managed to find what caused this error. But I do not understand the true reasons for this problem. For fun, I tested build with different values. In my case, the memory overload occurred due to the fact that after Text () there was .padding (with value) followed by .foregroundColor (with RGB). For clarity, I made a screenshot from Xcode:

Take a look. Maybe someone is also getting an error because of this, and you can get through this problem. Although for me it is a mystery why this is happening.

Post not yet marked as solved Up vote reply of BGDV Down vote reply of BGDV
  • I'm learning SwiftUI and there is some code that's similar to yours in mine. I removed the padding altogether and force quit swift-frontend and tried building again. Now there is no memory leak. Adding the padding attribute results in the memory leak

  • I went through all the comments in this thread. Many people talk about GeometryReader .... Yes! in my code the Text(), .padding() and .foregraundColor() are also in the GeometryReader. Maybe the solution to this ugly problem lies somewhere in this direction ...

  • Does seem to help. I had padding within GeometryReader in a few places. Removing the .padding() or its value seems to have fixed the problem - for now!

    I too am mystified…

Add a Comment

I can confirm the issue I originally posted is still present in Xcode 13.2

  • Working on XCode 13.1, Monterey - confirming saw the issue where SourceKitService & swift-frontend memory usage would each explode to around 40GB.

    I saw this issue fairly quickly - within minutes - of using GeometryReader in a project. After going through above thread, I decide to remove the code using GeometryReader, force quit above services, closed and re-opened XCode.

    So far, I do not see any spike in memory in the above services. SourceKitService is at about 70MB, XCode at about 1.11 GB. Launched app on device and so far, XCode and system is stable with above usage.

    Would love to know what the issue is here.

Add a Comment