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!
Related
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 a problem in iOS application that I am currently developing.
While running applications I am continuously having mysterious allocations of ~500kb.
I used instruments to track these allocations down, but the results are above of my knowledge.
So the instruments results looks like that:
As you can see there is continuos growth. Each "Generation" shows growth of approximately 500-600kb.
When I look into generation I see that the allocated memory goes to VM: Performance tool data:
If I go deeper inside I see that the responsible library is libBacktraceRecording.dylib:
And then if I want to check the responsible for allocation place in my code sometimes I see calls which are related to GCD:
And sometimes I get some kind of Stack Trace which doesn't directly relate to my code:
What could be the reason of these allocations?
It is not big amount, these 500-600 kb, but as it keeps growing after some time it kind of makes me worried.
As I understand these allocations probably are not caused by me but by some kind of xCode performance monitoring tools or something like that. But is it true?
And why it keeps growing without limit?
GMSPhoenixRenderer is the Google Maps rendering engine. More likely than not, it is gathering statistics related to performance or, as you say, it is the iOS dev tools doing so on its behalf.
You'll have to look in the GM* API to see if there is some way of disabling this. I would suspect it is only turned on in DEBUG builds.
My app is running out of memory. In XCode's memory report I can see the memory usage rise on the device to a little bit above 500Mb before it is shut down.
When profiled in Instruments (either with the allocations tool or the leaks tool) this does not happen. The process runs up to about 100Mb and balances out as it runs the memory intense portion of the task. The app does not crash when run in Instruments.
What would cause the discrepancy?
The intense process that runs is utilizing a UIWebView to determine the length of a number of pages of content. The web view is in the background and loads a page. On completion of the load it calculates the size and loads the next page until all pages have their length calculated.
Since I have been unable to get the same memory issues to occur in Instruments, I added logging to init and dealloc methods on all of the major parts and can confirm those are being allocated and released as expected.
After that, I tried assuming that allocation and deallocation was happening properly, but that I was just allocating faster than the system could reallocate memory. I tried stopping the process early before memory ran out to see if the memory usage would drop. XCode's memory report does report a small drop, but not by a significant amount -- even after letting it sit for a few minutes.
My next step is to try to simplify the process until the problem is eliminated.
Has anyone else come across something like this where an app in Instruments does something completely different than not in Instruments or have any explanation for what might cause that?
I would look at the two schemes and make sure the settings are the same. It's possible that the profiler is using a non-debug configuration and "Run" is using debug configuration.
I'd pay special attention to the "Enable Zombie Objects" in the "Diagnostics" tab of the "Run" configuration, as that can take up memory keeping track of all of the deallocated objects. Zombies are a wonderful diagnostic tool, but you want to turn that off in order to ensure you reclaim all of the memory associated with the deallocated objects.
For information on getting to the scheme configuration, see https://developer.apple.com/library/mac/recipes/xcode_help-scheme_editor/Articles/SchemeDialog.html.
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.