I am writing a game in Swift using SpriteKit with Xcode 7.3 on a Mac mini running El Capitan (both updated in last couple of days).
Shortly after I started, my Mac mini started crashing. The error log indicated that a Kernel Panic had occurred likely due to a memory leak & the process was identified as Xcode. Looking at the Activity Monitor, I can see that when this specific app is loaded in Xcode, the memory used by Xcode fairly rapidly increases even though the App is just sitting there doing nothing.
When other apps are loaded & idle, the memory usage stays more or less constant as you would expect. I have Googled for clues for several hours but can find only info. about memory leaks when an App is running & how to detect them with Instruments.
This is a weird one as far as I'm concerned. I do not have any idea how to start to figure out what's causing this other than starting with a fresh project & gradually adding code to see if/where it starts happening again. I would appreciate any ideas other Xcode users may have.
You don't happen to have
skView.showPhysics = true
turned on?
That is know to be causing memory issues exactly as you described.
There are a number of things you can do to start diagnosing this issue. Firstly you say that only one app is doing this. So this would indicate that the problem is an app problem rather than XCode. This is a good thing :-)
Next I would start using the profiler to monitor the memory and allocated objects in the app. try taking snap shots of the memory at regular intervals and look at what has been allocated since the prior snap shot. The profiler can then help you to dig down into the leaking objects and see where they are being retained and released. This might give you the clue you need.
Another thing is try is the profilers leaks monitoring. That also might tell you whats going on inside your app.
Lastly, is there anything in your code that is executing in some sort of loop. Something that animates on the home screen for example. Perhaps that is leaking.
Thanks very much to Drekka & Adrian B for your speedy answers but, as always happens, as soon as I post a question, I stumble across some information that leads to an understanding & (in this case partial) solution. Looking for an answer to a different question, I came across a thread on the Apple Developers Forum where several others are reporting the same issue.
It is related to the use of the SpriteKit Scene Editor. Hence it is app related in that for me it occurred with the only app for which I have ever used the Scene Editor but in reality it is an Xcode bug. What happens is that if the Scene Editor window is open (i.e. the .sks file is selected), even if the scene is blank, Xcode starts to leak memory at a rate of about 1MB/sec. If you close that window, the leakage stops. It happens even if Xcode is minimized. Apparently, it has been reported as a bug. I guess the work around for now is to accept the leakage while you're modifying your scene & then close the editor when you've finished (or do everything in code).
Cheers,
RB
Related
I’m having a memory issue. I get an error message “Thread 1: EXC_BAD_ACCESS(code=1,address=…) The error is elusive, and apparently timing-dependent. On my iPad mini, it usually averages about 3 minutes between crashes, on my iPhone SE it averages 10 minutes, and on the simulator it has run for 20 hours without crashing.
I’m not successful in using the Zombie detector. (See below for my experiences with it.) So I’m trying to go over my code with a fine tooth comb to see what might be causing the crash. What are the issues that might cause an allocation error?
My app is multi-threaded. It takes sound from the microphone, processes it, and continuously updates the display with the processed results. It’s written in Swift 3, so I’m not doing any explicit mallocs or frees.
I’m looking for places in the code that might cause an error. The two things I’m looking closest at are weak references and unsafe pointers. Are there any other common programming errors that could trip me up?
(The Zombie detector is useless. The Apple Instruments User Guide says, “For iOS apps, use the Zombies template with the iOS Simulator, rather than a physical device.” I’ve ignored the warning and tried it with my iPad mini, and I can’t get it to crash. Everything runs at about 1/10 speed, and when I pause the recording, my OSX machine gets sluggish as well, displaying the spinning “Wait” cursor for minutes at a time. The total memory allocation goes up and down, but stays within limits, so there is no major memory leak. I’ve also run the Zombies instrument on the simulator as well. It’s equally sluggish, and it still doesn’t crash.)
The issue in this case turns out to be thread safety. If I set a UInt8 variable on one thread and read it on another thread, it can lead to a memory error. The setters and the getters are not thread safe.
(I’ve been programming computers most of my professional life, mostly in C, C++, and Java. I’m familiar with the multi-threading issues in these languages. I’m new to Swift 3. It simply hadn’t occurred to me up to now that setting and getting numeric variables was not an atomic operation — that an ill-timed access could cause a program to crash. I’m going to have to drastically rethink my approach to concurrency with Swift.)
This question is a follow up question to the answer of this: instruments-leaks-and-allocations-tvos
The initial question relates to a memory leak I had in a tvOS app, but I think the answer to this question is relevant to iOS/Xcode/Instruments development in general.
The issue was solved by removing a closure inside another closure keeping a reference to a variable in the first closure. This caused a retain cycle.
Question
I really want to understand why I didn't find the issue earlier, let me explain.
How it turned out, I used Instruments the wrong way. My workflow while profiling was the following:
From Xcode, I Run the app on the Apple TV device
Start up Instruments
Attach Instruments it to the launched app
The following was visible in Instruments:
There were some leaks, but nothing that special. The graph didn’t really increase, not even after an hour. I used this method for a long time, and never thought something could be wrong here.
While reading about leaks, profiling etc. I came across some random article where someone was using the Profile button from Xcode (instead of Run). I just thought this was doing the same I was doing: Running the app, starting Instruments and attaching the process. But, magically, this graph appeared:
Clearly there is a memory leak here and using this data, finding the leak was pretty easy to do.
So I really want to know what is the difference between these 2 approaches, but I can't make anything out of it. Anyone :) ?
PS: The screenshots were made 2 minutes after each other with exactly the same codebase, just a different way of connecting Instruments to the process.
The difference between the two approaches is when you choose Profile from Xcode, Instruments records all the memory allocations from the start. When you run the app in Xcode, launch Instruments, and attach the app, you're going to miss all the memory allocations that occurred before you attached the app to Instruments. Choosing Profile from Xcode is the better option if you want to record every memory allocation your app makes because it starts recording from app launch.
To answer your question about why Instruments has different data when you choose Run and Profile in Xcode, I suspect it's because they run different builds of your app. Xcode is initially set to use the Debug build configuration when you choose Run in Xcode and set to use the Release build configuration when you choose Profile. Instruments can show different memory usage for debug and release builds. You can edit your scheme to see the build configurations used for running and profiling.
I have started receiving app termination due to memory pressures very recently (mostly with iOS 7). The app used to work very well on iOS 6.
The app is mostly uses a UIWebView to display a webpage. However for a few webpages it creates ever increasing Dirty memory with most of it due to Image IO and Performance tool data (see attached instruments screenshots). I am completely clueless as to where to dig next. Could someone guide me what should I do here onwards? In the second screenshot I see a sudden bump in the memory allocations. Is there a way to spot the process/part of the code which caused it?
EDIT One can reproduce these results in a simple demo kept at www.github.com/nikhiljjoshi/iosCrash (just change the site to www.nzz.ch).
Thanks in advance,
Nikhil
I’m helping out a company with a project for iOS, which is using Core Text. Some users of the app have reported that text is occasionally missing from within the app. It seems™ that this is somewhat memory related, because it’s solvable by shutting down the app along with background apps.
I made a few lines of code which simulates the use of the app – so the app “runs itself”, navigating between view controllers randomly, scrolling in text fields etc – to track if this issue occurs by normal use.
I’ve found some memory leaks related to the use of Core Text, but according to instruments the amount of memory lost is quite low. However, when the simulation has been running for about 20 minutes or so, the app is shut down by the os because of memory warnings.
I’m intending to fix this memory leaks, but my problem is that I will not be able to ensure that this fixes the main bug (missing text), since I cannot reproduce it myself.
So my final question is: have anyone experienced issues with missing text on iOS while using Core Text, which are due to leaked memory? Does it sound plausible? If so, is this related to only specific versions of iOS?
I appreciate any answers that can help me out!
UIViewControllers may implement didReceiveMemoryWarning that the system calls when your app is on low memory. Framework classes, as core text, are most likely do implement this and act accordingly to save memory. So it is possible that your core text object aims to help your app resolving the low-mem situation with freeing some of its resources that can even cause it to blank its contents. Fix first all memory leaks in your app.
On the other hand, all bugs are very difficult to correct if you can't reproduce them. If you suspect that the issue is due to low memory, try to simulate this yourself by allocating huge amount of memory in your application and hope that you can reproduce the erroneous behavior that way.
I am creating apps for the Ipad and its driving me crazy.
The memory that is usable by the apps changes depending on what other apps were ran before it.
There is no reliable set amount of memory that can be used by your app.
i.e. If safari is ran then even after it closes it takes up some amount of memory which effects other apps.
Does anyone know if there is a way to clear the memory before my app runs so I can get the same running environment every time?
I have created several prototype apps to show to other people and it seems like after a few days they always come back to me and tell me that it crashes and to fix it.
When I test it, the reason is always because there is not enough memory (when there was enough before when I was testing). So I need to squeeze every bit of memory (which usually effects performance due to heavy loading and releasing) out of the app and tell them to restart their ipad if it continues to happen.
I read in a book that generally apps can use at max 40mb or so, most of the apps that crash are crashing at around 27mb. I want my remaining 13mb!!
While you will get a pretty good state after a reboot, what you really should look for is clean memory management and avoiding leaks.
Using the available memory wisely is solely up to the programmer. Don't tell your users to reboot the device, ever. And with every update of the OS memory things might change anyway.