Today I faced a problem that there is one memory leak in my iphone application.
below is the screenshot.
when I double click the leak block,
the memory leak detection instrument gives me some assembly code not source code
so I could not find out where the memory leaks,I confused me a lot,and last night I didn't
sleep well.
Could someBody give me some advice to deal with such things?
Thank you!!!
It looks like this leak is being caused by a closed source library, so you wouldn't be able to directly change the code.
You should make sure that you are properly using the framework methods, as sometimes your actions can indirectly trigger leaks with private API's and Instruments is pretty bad at catching and properly reporting that kind of thing.
A good place to start might be Build and Analyze.
Related
I know this question is subjective but I am brand new to Objective-C and the MacOS. Although I am trying to be diligent in my memory management I am sure my code is leaky. Can someone suggest a good tool to detect these leaks?
Thanks!!
There are leaks and then there are leaks.
Leaks is strictly defined as an allocation in memory for which there are no remaining references to said allocation and, thus, no way your app could use it again. As Bogatyr said, The Leaks instrument does a great job of tracking these down.
However, you might find that your app is still growing over time, a sure sign of a an additional problem. Regardless of whether or not it is truly a leak, such potentially unbounded growth in allocations is obvious very bad.
For that, use Heapshot analysis. I wrote a guide to doing exactly that people seem to dig. Maybe it'll help you, too.
Xcode has built-in tools, these are what developers typically use for debugging performance and memory issues. You can access them via the Run -> Run With Performance Tool -> Instruments -> Leaks. Also very useful in the NSZombies tool (here's one tutorial on using it: http://www.markj.net/iphone-memory-debug-nszombie/
In XCode you have an option, Build & Analyze (Shift-Cmd-A), that will check memory issues for you. This will find some of the memory management problems, but not all.
Note: Before running it, you may want to clean your target (Shift-Cmd-K) to make sure all project files are compiled.
After that you can use Instruments, with Leaks or Zombies as mentioned in the other answers.
I'm somewhat new to Objective-C and while I think I've got a decent grasp of memory management, I'd like to become familiar with the best ways to test this (if possible).
I know of two options: 1) Build and Analyze (from within Xcode) and 2) Instruments.
Are these the best tools for the job? How accurate is the Build and Analyze feature? I've not used Instruments yet, but it looked somewhat complex when I tried to get started.
I realize the best approach might be to study the Objective-C language itself, but I'm looking for supplemental ways to test this.
Thanks for any insights.
I see a lot of people stating that "Instruments can track down leaks [in context of memory management]" and leaving it at that.
So far from the truth; the Leaks analysis is useful, but barely scratches the surface of the awesome optimization opportunities it can reveal.
Can be used for Zombie detection; i.e. to track down the over-release of an object that causes a crash
Can monitor the allocation bandwidth; the # of objects your app creates/deallocates over time. Reducing that is a very effective means of optimizing an app.
Can inspect the exact set of objects live and in memory at any one time; the working set.
Using Heapshot analysis, can show you exactly how your app permanently grows over time.
Can tell you exactly where any given object is retained and/or released, including backtraces.
The static analyser will attempt to find errors in your code by inspecting it without running it. It's really good at spotting times when you accidentally make an allocation error. It'll tell you about things that are unarguably going to cause a problem and occasions when you've stepped outside of normal Objective-C conventions. So don't necessarily be confused if it highlights something you think won't lead to a problem — Objective-C is a combination of rules and conventions and the analyser looks for breaches of both.
Instruments will look for leaked objects at runtime. So it can find only problems that actually occur. So in principle you'd need to go through every single potential usage path in your program to catch everything. It tends to be really useful in practise though. And it's not that complicated to use. Just launch with the leaks instrument, run for a bit, you'll get a graph of when memory is leaked and you can find out what sort of objects are being leaked. You can then ask to be shown where in the source the object was created. Keep in mind that you'll get some secondary leaks (in that, if one object leaks then all the objects it was retaining will also leak).
On the desktop Guard Malloc is also available, though I think it isn't yet on iOS. That causes your program to run a lot more slowly but will cause it to crash immediately upon any memory access error. So that's really helpful because normally things like writing past the end of C arrays or accessing deallocated objects may cause an error but won't necessarily do so, sometimes causing bugs in some part of the code to corrupt structures used by other parts of the code and cause a crash in code that's completely valid.
Yeah the best thing you can do is to learn more about memory management http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/MemoryMgmt/MemoryMgmt.html
Build and Analyze works pretty well for determining some things like if something is never released. It will help you track down alot of problems, but it is by no means perfect.
Instruments will help you track down leaks but it is a little harder to use and track down exactly where things go wrong.
Another helpful tool you can use to track down crashes from memory is to click Run->Stop On Objective C Exceptions. Which will let you go through stack traces of where your application crashes to find out where it goes wrong.
I'm fairly new to Objective-C (come from a Java background) but I was able to get by with the two features you mentioned (Build/Analyze) and Instruments. I think those worked because I got my app approved by Apple and haven't had any customer complaints so far, so at least that's something.
Anyway I found Analyze to be far less helpful than I would have thought. Mostly I found problems by using Allocations and Leaks Instruments.
Analyze didn't find things that I think they could probably check for. An example would be not releasing (or autoreleasing) an object that you alloc/init and then assign to a retained property. You can even search your source for every time you use alloc and then just do a double check to make sure you're doing correct memory management for each case.
Leaks instrument was very helpful, but make sure you put your app through the ringer while its running. Just click on all sorts of stuff, go in and out of screen lots of times, click on things people would never do, etc. You will find the leaks. Then crush them. Very satisfying.
Clang with xcode is another great option. http://clang-analyzer.llvm.org/xcode.html
I'm new to iphone and objective-c development and want to ask if Clang Static Analyzer is enough for getting rid of memory leaks? I personally found the xcode "Leaks" tool rather difficult to use, besides I've seen some articles, where it reads that it will always show memory leaks, even if there are no any real leaks.
If I don't have any warnings from clang analyzer, does it mean that I don't have any memory leaks? Or I need to check it somehow else?
What do you think?
Thank you very much.
No it is not. CSA is a static analysis tool, meaning it can only catch things that can be reasoned about at compile time. To that end it also isn't perfect, far from it. It is definitely no substitute for Instruments. CSA can however, help remind you of things in the rules, and other potential problems.
If you are using the built in Build and Analyze, you can get better results by downloading the real scan-build and turning on all checks
http://www.loufranco.com/blog/files/scan-build-better-than-build-analyze.html
But, it's still not enough. You need to check for leaks using run-time analysis. If you keep to very simple alloc/retain/release rules, you might be able to get away with it (or so close, that the Leaks tool becomes much easier to deal with).
No, the static analyser is one of the tools that is handy to have but you shouldn't rely solely on it.
Instruments and in particular the Leaks and Memory allocation tools are great ways to find leaks. The memory allocation tool can help you find leaks that leaks can't because it can show you the overall memory usage, if you notice it going up but never coming down after you finish a task you can start looking for a possible leak...
I'm looking to clean all my app's leaks.
As you can see on the picture below, SQLite makes a lot of memory leak.
I do use SQLite through CoreData. The strangest thing is that AdresseBook is making all the libsqlite3 leak and I never use the AdressBook!!!
Do you have an idea?
Thank you :)
Leaks http://img196.imageshack.us/img196/3997/leaks.png
CoreData doesn't produce any known leaks, therefore your app must be triggering this somehow. AddressBook is a relatively ubiquitous framework on the iPhone in that other system frameworks will end up pulling in AB and AB's data.
Thus, there is something in your app that is triggering the use of AB which is then triggering the use of CoreData.
In any case, since you don't use SQLite directly, you should focus your analysis efforts higher in the stacktrace; at the interface between your code and the system frameworks. Looking at that screenshot, there are two suspicious attributes:
Frames 46, 47, and 48 don't have symbols. Are you running a debug build? If not, do so and those frames should be resolved.
There is a bunch of thread related stuff mentioned. Are you absolutely certain you have done your threading correctly? It is quite easy to create leaks in a threaded application.
(There is also the possibility that these "leaks" aren't really leaks, but are false positives. Probably not, but there is a slight chance you are chasing ghosts)
In any case, the best approach to fixing leaks is to focus on the easy leaks first -- the ones you understand -- and see what remains. Many leaks are often the by-product of other leaks.
Can we see the entire trace?
Also I'm guessing you've already run the static analyser? If not you can find it by going to: Build -> Build and Analyse
While developing my app I have come to realize that the majority of my app crashes have arisen from poor memory management.
I understand I can print or log retain counts through NSLog (#"retain count is:%d",[myInstance retainCount]);
But isn't there a better, less manual method? Possibly a visual representation of your objects and instances?
answered. Cheers, Adam & Jason. :-)
Use the Leaks and Object Allocation tools through XCode.
Run > Start with Performance Tool > ...
In addition to the other answers, I would highly recommend using clang to do a static memory analysis of your code. It won't catch every memory-management error, but it does catch quite a lot. If your chief problem seems to come from memory management errors, clang will go a long way toward finding those errors. Clang is free, at http://clang.llvm.org/
As Adam suggests, Instruments is a very useful tool for these kinds of things. It's fairly easy to use, but can be a bit overwhelming at first. I suggest perusing the Instruments User Guide as you get started. It's pretty easy to follow and is helpful until you've used Instruments for a while. Even without reading the guide, however, Instruments is still far easier and more intuitive than littering your code with NSLog() calls and trying to parse the output yourself ;)
I also find the NSZombie trick useful for tracking down cases of over-release objects.
Basically the link describes a 'trick' so that release'd objects get replaced by NSZombie objects which if they get released again throw exceptions.
You can then use Instruments to track back to where the object was allocated.