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.
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've tried to read almost every decent tutorial in the internet, but still can't understand what is really happening here:
I've "Hide System Libraries" and "Invert the call tree", but I do not understand how to find actual code responsible for for example this leak. Any tips are appreciated. May be I am missing something obvious. I am getting hundreds of leaks, however I am using weak in closures, I do not have classes referencing each other etc. But it looks like I am missing something fundamental.
The problem shown in your screenshot is Instruments can't find your app's debug symbols. Instruments is showing memory addresses instead of function names. You are not going to be able to find the source of your memory leaks in Instruments without function names, even if you invert the call tree and hide system libraries.
Make sure your project is generating debug symbols. Check that the Generate Debug Symbols build setting is set to Yes. If your project is generating debug symbols, Instruments may be unable to find the dSYM file that contains the debug symbols. In Instruments choose Instrument > Call Tree > Locate dSYM. The dSYM is usually in the same directory as the release version's application bundle. The following article has additional information:
Instruments: Locating dSYM Files
Memory leaks can be difficult to track down. This is likely going to be a time consuming process, so be prepared. In the end, there is usually a lot of trial and error with debugging memory leaks. The "Memory Leaks" instrument has actually only detected one leak for me in the past. I've always had to track them down myself using the "Allocations" instrument.
One of the things that has helped me in the past is to start by trying to figure out what objects are actually being leaked. Click on the allocations instrument (the row above "Leak Checks"). Now try sorting by number of objects released or amount of memory used. See if there are any objects that have a count of 0 released when they shouldn't be sticking around. See if there is an object type that is taking an abnormal amount of memory.
Memory leaks are always due to developer mistakes with memory management. There are some minor memory leaks that exist in some of the lower level private APIs in Foundation and UIKit. At those lower levels, they are dealing with a lot more manual memory management, so its much easier to make tiny mistakes. You can't really do anything about those, but they are relatively rare.
If your application is working just fine, you may not need to worry about fixing these. There is some cost benefit analysis you want to do here. If this isn't impacting performance or stability, is the time investment in fixing these right now worth the minor benefits it will provide you and your users?
However it is worth nothing that memory leaks can add up, so if a user has your app open for a long time, the amount of leaked memory will eventually become a problem if you continue to leak more objects over time. At some point the application will crash and the user will have to re-open. But if your memory leaks are small enough that this doesn't become an issue unless the app has been open for HOURS, is it really that much of a problem anyways? That's always a judgment call on your part.
I am working on an iPad App that is built with Appcelerator Titanium Studio.
The app works great in simulator, but it crashes every now and then in the older models of iPad. So, I decided to see what's happening with the app by letting it run in simulator and using the XCode Instruments to see any leak.
As expected, there appears to be some leaks, this is what I can see in the report:
I have no idea what this thing is reporting back. How do you use this report to find the leak in your app? Has anyone got any experience with this?
memory leaks is all up to your code. There are no specific memory leaks you can just point to. However, there is a pretty good blogpost with some great basic rules you will have to follow to prevent memory leaks.
In case there are any memory leaks in Appcelerator's code, you will need to report it to their JIRA. However, my app for example is pretty big and I haven't encountered any so far. And if there are, they are tiny, as the memory usage is pretty consistent.
http://www.tidev.io/2014/03/27/memory-management/
If you want to locate the memory leak, try "Allocation" instrument.
You can follow this article.
as the title says, I have an app which works on iPad 2, but crashes on iPad 3. when running it the console gives me a low memory warning message. When the crash happens I symbolicate it, but there's really nothing that I can relate to the code, like it shows
process name, UUID, rpages, recent_max, [reason] (state)
and under those column headers just hexadecimal stuff, nothing showing method calls or lines in the project.
Any ideas? am I missing some flags in the code that allows for a better crash log?
Thanks.
If you're getting low memory warnings and fail to release enough memory to resolve the issue, your app will almost certainly crash. The thing is, I don't think that the particulars of how or why it crashed can possibly be illuminating. At that point, you're evaluating secondary symptoms. You really need to go back and figure out why you got the low memory warning in the first place and fix that problem.
As Daniel said, you can look at Technical Note 2151, but as it says:
When you see a low memory crash, rather than be concerned about what part of your code was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. Memory Allocations Help lists detailed steps on how to use the Leaks Instrument to discover memory leaks, and how to use the Allocations Instrument's Mark Heap feature to avoid abandoned memory. Memory Usage Performance Guidelines discusses the proper ways to respond to low-memory notifications as well as many tips for using memory effectively. It is also recommended that you check out the WWDC 2010 session, Advanced Memory Analysis with Instruments.
So, a couple of thoughts:
Have you looked for leaks? The Finding Leaks article walks you through how to use instruments to find your leaks.
If you turned on zombies, have you turned them off? Zombies is a great diagnostic tool, but just consumes memory.
Have you run your code through the static analyzer (shift+command+B or select "Analyze" on the "Product" menu)? Especially if using non-ARC code, this can find lots of memory issues.
Have you examined your allocations for unexplained increases without offsetting decreases with the Instrument's Allocations tool. Using that, you can run the program, look at the consumption of memory on the graph and see if you see any increases that aren't offset at some point by the corresponding decreases. And if so, highlight those increases in the graph:
For example, when running the Allocations tool, hold down the option key and then click-and-drag with your mouse to highlight a portion of the timeline, to identify what you want to inspect. You probably want to focus on one of your spikes in allocations. For example, I found a bump in my allocations and highlighted it as such (this was a ludicrously simple example where I create a huge array in viewDidLoad, but hopefully it give you the idea):
Note, I find it useful to show the call tree in the lower panel, it's often useful to select "Hide System Libraries", to focus on your code (and "Invert Call Tree", too). And if you double click on the method name in Instruments (in my example, here, it would be viewDidLoad), Instruments will then show you your code that's doing the allocation:
Low memory warnings generate a different kind of log than standard crashes. Take a look at the "Understanding Low Memory Reports" section of this article to understand what happened with your application and how you can debug it using Instruments: http://developer.apple.com/library/ios/#technotes/tn2151/_index.html
After spending time with FastMM4 in weeding out any pieces of code that could possibly cause memory leak as indicated by FastMM4, we have been test running our software for about a month non-stop on Windows 7. This is what I am seeing so far in the Task Manager for my software process.
> -CPU started out at 1% and 0%. Now it is bouncing around from 2% to 5%
> -VM usage started out at 11,852KB. Now it is at 4,900kb but bouncing
> around from 4,900kb to 5,000kb.
Does this mean we have memory leak in our software? I am confused and concerned.
Thanks in advance,
That sounds like pretty normal memory usage. The program does something that needs memory, and memory usage goes up. The program gets done with what it's doing and releases the memory, and memory usage goes back down. A memory leak is when memory usage goes up and keeps going up because you're not releasing the memory once you're done with it.
If you've got FastMM4, you shouldn't have to hunt around for things that might possibly cause a memory leak. Just turn on Full Debug Mode and the logging option and it will find any memory that leaks when you run it, and write out a file with types and stack traces for you.
No, when memory usage goes up and eventually your application uses all available memory, you have memory leak and reason to be concerned.
Even if an application seems to run fine for days, there still can be memory leaks hidden in code areas which are not (or not frequently) used. So they can be a problem, when this part of the application becomes active some time later.
To make sure that all code is tested for leaks, you can use FastMM4 with unit tests (with DUnit), ensuring to execute as many code paths as possible. Unit test code coverage can be measured for example with this open source Delphi tool, or Discover which recently became open source.
Also, DUnit in the trunk version (9.4.0) supports automatic memory leak detection (based on FastMM4) for every test case.
May be worth to think about the debugger? I've understood that you do not use them. I also had problems with memory leaks. I just had no guessed about it. Now use the "guardian" of the leaks - for me it became deleaker. And you can look such one, that will please you.