I’m trying to build my Swift app and, as the title states, it never finishes building and eventually I get a warning for critically low system memory. I have about 23GB free on my computer but as soon as I hit build and watch the memory usage on Activity Monitor the Swift process gradually increases in size, reaching tens of gigabytes in size until my computer dies. This only recently started happening but I don’t know how to solve it. It also seems to happen whilst Xcode indexes my project. It gets stuck at the "Compiling Swift sources" stage. Does anyone have a solution?
I solved it! The problem was I had a function that was a bit complex and it was returning a value, but I had set the function as void. I tracked this down by removing files that I'd recently changed from the target and then compiling to see if it would give an error or just compile forever. Then I commented out bits of code.
I solve it by cleaning the code first (shift+command+K)...
Then keep it free for indexing...
After that rebuild (command+B)...
And it works fine...
Related
When my Windows 10 app runs, it causes a process called Runtime Broker to execute, which takes up a lot of Memory space.
I know my app isn't "Memory-hungry" and it hardly takes 80 MB of RAM to execute. But from the time it starts, the Memory used by Runtime Broker keeps in increasing until the PC gets stuck.
Upon killing that process, the app is force closed by Windows.
I would have posted my source code here, if only I knew which part of the code is causing this to happen.
What are the possible technical reasons for this problem to happen, and what are the possible fixes in my code to prevent this?
Is there something wrong with my code, or is it some API that I am calling?
You can easily delete RuntimeBroker.exe and any other file. I deleted RuntimeBroker.exe and Livecomm.exe by booting a live Linux Dvd and after loading go and mount the c: drive then simply navigate to the file and delete it. Done!
Runtimebroker seems to hold about 60k per file held via StorageFile objects. It's still a bad problem and the only solution is to not hold on to very many of these.
Microsoft just never does anything about this.
Update: Microsoft seems to have quietly ditched UWP. The replacement has "WinUI" and is probably called the Windows App SDK at the moment. No more runtimebroker.exe.
Our iOS automation tests on simulator have gone through disaster since upgrading to Xcode6.
We can observe view switching slowing down, UIAutomation felt it too and often returned an empty or not fully updated app main window, you can imagine the stability.
Part of the reason is that we have slow VMs, but still we need to find ways to workaround it.
Then I notice there's the CoreSimulatorService process staying alive between the launches and shutdowns of simulator. So I killed it to see what change would it make:
killall -9 com.apple.CoreSimulator.CoreSimulatorService
After it was killed and relaunched, the performance of simulator seem to get much better, at least I don't see random fails anymore (hopefully). I guess this is kind of cleaning up.
So I hope to get a better idea about what function does CoreSimulatorService perform exactly?
Also, I am confused about where to find the documents when Apple releases new things (forgive my ignorance). For example, I didn't find any documents in iOS developer library mentioning simctl except Xcode Release Note.
Thanks!
I just faced a unexpected CPU spike due to this process (Xcode 12 & macOS 12).
A quick look on the web showed that most of the time your look for com.apple.CoreSimulator.CoreSimulatorService you will find people afraid of "something" and that are resetting everything. Ultimately this will "resolve" (as a workaround) the problem that isn't really one.
I opened ActivityMonitor (and not just looking at iStat Menu CPU widget), I found that the process update_dyld_sim_shared_cache was responsible for this CPU high usage.
Just reading the name show that the process is probably doing something expected after all (I got this issue after an OS update).
I just waited a around half a hour and the CPU went back to normal.
Since installing XCode 6 GM, it has been freezing and locking, showing the spinning wheel of death while I attempt to edit code that has syntax errors. Has anyone else seen this, and are there any known work-arounds?
I foolishly abandoned my cautious strategy of saving the previous version (Beta 7) and it appears that Beta 7 is no longer available for download. Are there any known archives of / for the link?
I have also posted to the dev forums and will follow up with a bug report, but it is hard to pin down the exact circumstances.
Edit:
Additonal Notes:
CPU: SourceKit Service is generally around 100%, but that has seem to have been the norm for the flavors of XCode, and the CPU seems to properly drop off when it finishes recompiling.
RAM: SourceKit is no longer exhibiting the memory leaks that used to cause it to halt and catch fire, memory does not appear to be a factor, and there are several ~ 5+ gigs to spare.
Environment:
Late 2012 Mac Mini, 16GB RAM
OS X 10.9.4 (to be fair, this was new today as well, driven by the requirements of XCode 6 GM).
That said, only the software changed today.
Update
Apple claims that this bug is fixed in Beta 6.1, for what it's worth.
You should look if you have any imports missing in your bridging header file. Sometimes even commented out imports will cause this behaviour. For me it was commented out Pixate Freestyle Cocoa Pod. I had to remove pod completely from my project to stop SourceKitService from crashing.
https://stackoverflow.com/a/25173389/527539
I can't say any of these fixed the issue, but they alleviated the situation:
I removed all playgrounds from the project tree. Saved them somewhere else.
I removed all objectiveC code from the swift project (when possible). This Spinning-wheel, BTW, is a problem only in my swift projects. My other Objective-C-only projects are fine.
It looks like it's the background indexing process which is taking all the CPU. Open "Activity Monitor" and see it right there at the top, using 360% CPU. Lowering the priority for this process helped as well (type in terminal):
renice 10 -p [pid]
Make sure to take the correct process id from Activity Monitor.
The higher the number (should not exceed 19) the lower the priority.
I make significant changes one at a time. It seems that the amount of errors in the file affect how many times and for how long the spinning wheel spins. It looks like some type of errors trigger it more often than others, but I'm not able to pin point which exactly.
XCode had a similar indexing issue in previous versions (see this Xcode4 issue: How to disable indexing in Xcode 4?) which gives me the hope they will fix this issue sometime, hopefully soon...
I create a new tab via menu File->New Tab and close the old tab that is frozen.
CmdT does not work that time.
I thought that my computer was getting slow cause of the loop in the glfw loop:
while(!glfwWindowShouldClose(window)){
...
}
But when I run it the CPU usage displayed in XCode is just 15%. I wonder what may causing this whole slowing down situation in my system when I run (debug) my project.
I don't think that is this loop, cause I ran a silly code in another project:
while(1){
printf("blah\n");
}
...And a loop that didn't broke yet, obviously, doesn't mean that the system is putting all the CPU effort on that. So, I wonder why this specific project is slowing everything down.
My code is on Git
Lots of times Xcode (seemingly randomly) starts to run extremely slowly- it can take around fifteen seconds to move an object in IB, or compiling after changing one line of code can still take up to ten seconds. I took a look at my Activity Monitor, and this is what I found:
My question is, is this normal?
2GB of RAM is way more than enough, even for latest versions of Xcode.
Looks like you've hit one of the bugs in Xcode compilation / indexing / syntax hilighting. c.f.: Xcode 4.3.2 and 100% CPU constantly in the idle time
You only have 2GB's of RAM. With each update to Apple's software, they get more memory intensive. The same goes with Safari 5.1+. So to answer your question, Yes, this is normal for a machine with 2GB's of RAM running Lion as well as other memory intensive applications, Chrome being another.
As for Interface Builder, I have noticed this too. XIB's are XML files, so I believe as you move an object, Interface Builder is writing it's location on the view as it is moved, so that is a very data heavy task as well.
XCode is usually around 20-30% CPU sitting in the background doing nothing. It's a pig that's all.