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.
Related
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
I am working on an iOS app in Xcode. Earlier I got it to start and run, up to a limited level of functionality. Then there were compilation failures claiming untouched boilerplate generated code had syntax errors. Copying the source code into a new project gets a different problem.
Right now, I can compile and start running, but it states before even the launch image shows up that the application was closed due to memory pressure. The total visual assets is around 272M, which could be optimized some without hurting graphical richness, and is so far the only area of the program expected to be large. (The assets may or may not be kept in memory; for instance every current loading image is populated and my code never accesses any loading image programmatically.) And it crashes before the loading image has itself loaded.
How can I address this memory issue? I may be able to slim down the way images are handled, but I suspect there is another root cause. Or is this excessive memory consumption?
Thanks,
Review the Performance Tuning section of Apple's iOS Programming documentation. Use Apple's Instruments application to determine how, when, and how much memory your app is using.
One approach you should consider is to disconnect the graphics resources from your application, and add them back one-by-one once you feel they meet the requirements and limitations of iOS.
Now, this part of my answer is opinion: it sounds like your app is a high risk for being rejected from the App Store, in case that is your intended destination for this app.
We are trying to write a tool that would detect any new memory leak added to an iphone app in an automated way. This would basically be a test that would launch the application, run some actions on the app, and then invoke the 'leaks' tool to find out the memory leaks.
Now, the problem is, that when we are launching the app , doing some actions, and running leaks command line tool, we are getting different number of leaks every time. We are making sure that we are doing the same actions on the app, and wait for exactly 'n' seconds before we run 'leaks' tool. However, the total number of leaks that we get varies a lot (from about 120 leaks to 152 leaks).
Does anyone have experience running this tool, and know if its a known issue with this tool? Any ideas on how to fix this?
Thanks!
I've just kind of been 'winging' it with long tests (for hours) with no crashes, and eyeballing my code for quite a while and made sure that everything looks pretty kosher as far as memory leaks. But should I be using instruments... is it mandatory to do this before uploading to app store?
I think that using Instruments is not only good practice, it's strongly recommended by the iOS development community as a whole. Even if your app seems to run fine, you still may have leaks in other use cases. Test your app thoroughly with Instruments before pushing to the App Store or you may be in for a lot of users on older generation devices complaining that the app crashes.
Some of the most crucial tools:
Leaks
Allocations
Time Profiler
Another suggestion alongside using Instruments is to compile with the -pedantic flag.
In addition to what Yuji said, turn on as many warnings as you can in the build settings, by default these are off.
No.
But at least run "Build & Analyze" in the XCode. It tells you what it can find about the memory leaks, just by analyzing the source code statically. It's basically eye-balling the code by the machine. It's infinitely better than doing that yourself. If there're any warnings issued, fix all of them. It's rare for the static analyzer to give false positives.
Also, running your app with Instruments is helpful to see how it really allocates memories. Sometimes it's fun, too.
I would never publish an app without running Instrument's leak tool.
I often miss a release somewhere. And even if I read the code 200 times I would not find it without Instruments.
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.