I have a tab bar app with 4 tabs and nothing spectacular in the code.
All simulator testing is fine, there are no crashes with the app, everything works great, there are no warnings or errors shown up in Xcode (I am using Xcode 4.2 and the app uses storyboarding).
When running 'analyse', there are no leaks, errors or potential leaks in the code.
When running 'leaks', no leaks are listed, and I can load, reload, swap between tabs, etc, and all is fine.
When I run this on an iPhone, though, lots of leaks show up!
Some of them seem to be in code that is all released and looks fine, and all validates fine within Xcode.
Why is this different running on the phone from the simulator, and how can I find and debug leaks that dont show up when running leaks on the simulator?
First, by limiting the inspection range (with the left and right range buttons) to the area where leaks occur, you can inspect a smaller area. Then, by selecting some useful checks from the Call Tree on the left hand side, like Show Obj-C only, Hide Missing Symbols, etc.. then you'll get a lot more useful info from the Instruments. After that, click on one of the lines related to the leak, open Extended view and start examining your call stack. Also, as far as I could remember, double clicking on a leak line can take you to the source code where the leaked object is allocated. Be careful here, because it does not show where the leak happens, it shows where the leaked object is allocated. So, you should follow what happens to these objects, then.
And about the difference between simulator and the device, you can check this SO question.
Hope these help!
Related
While developing apps in Xcode memory leaks are occurring. When I checked them in extended detail view they are showing different methods that are not related to implemented. How to exactly find out which object is leaking and where it is leaking memory.
When ARC is enabled we have to take care of memory leaks or not?
Even with ARC memory leaks can occur, it just inserts release and autorelease during compile time.
1. You must check for leaks using Build and analyze in XCode, shift+command+b you should be clearing those issues.
2. After that you can start using the instruments by using profile option command+i . This will point you to where the leak might be.
This link will help you too http://soulwithmobiletechnology.blogspot.in/2011/04/how-to-check-memory-leaks-in-xcode-4.html
Edit: Added some screenshots to hopefully make it clear.
During profiling after selecting leaks choose the call tree option and check the boxes hide system libraries , invert call tree and show obj-c only as shown in image below.
After double clicking the symbol name below you'll get the line where it is leaking.
You'll get something like this.
Yes, even with ARC there are memory leaks. ARC is not a garbage collector, it only inserts for you, at compile time, retains, releases and autoreleases in key positions. So although it does help the developer, you should be aware that memory leaks still exist (for instance circular referencing). You can start by using the Static Analyzer and correct any problem it shows you. You can then go to Instruments and choose Leaks.
i m facing big problem with system libraries allocations.
i didn't get any leaks from my application still so much allocations.i attached various screen shoots. in my application using custom picker which get all images from assert library.which are pick from picker showing images on scroll view.
its screen shot when my app with 35 images on scroll view.if again i pick images from custom picker allocation increased.i am seeing object details its all related to frame Work allocations.not from my application
see the allocation object list response library is DYLD.
its my leaks screen shot
how can we release these allocations? please help me out ?
Just because you have no leaks doesn’t mean you are managing memory correctly. What you have is what I call memory bloat — you are retaining it longer than you need to. (A leak is allocated memory with no references. Bloat is allocated memory that has a reference but should have none.)
http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ will give you some good strategies for using Instruments to find them. (This is a very credible source, so far as I know he still works at Apple.)
make sure your application has no leaked objects and they will also disappear in instruments. For sure its pointing to a system library but it is always a result of your bugs. Select one of them and open the right view. Probably it will show you the right code stack and the allocated line of code.
The other thing you can do: run the static analyzer Product->Analyze it will find all (at least most) your leaks ;)
If ObjectAlloc cannot deduce type information for the block, it uses 'GeneralBlock'. Any strategies to get leaks from this block that may eliminate the need of my 'trial and error' methods that I use? The Extended Detail thing doesn't really do it for me as I just keep guessing.
I find that sometimes if in the leaks instrument you click the button that looks something like this:
{= and drag your app delegate file onto the screen, it will lead you in the right direction by highlighting the code that allocated that leaked block.
Every time it goes into a function call drag the source file with that function onto it. This can be hit and miss though as sometimes these mystery leaks aren't tracked back to the delegate.
In XCode, you can try build and analyze. Sometimes it can be helpful in finding leaks and sometimes not. But it's worth a shot.
I've just started using objective-c and xcode (version 4) and it appears that by clicking on the leaked object in the memory profiler, you can see exactly the point in the code it is referring to in the "extended detail" pane. In here it shows you a stack trace and clicking on a point in the stack will take you to the exact point in the code where the leak is occuring. Not sure if this was available in v3. Hope this helps anyone else tracking down a leaky GeneralBlock-16.
I have an app that has a tabBar Controller and a navBar Controller. It has ~8 views (a variety of web, table, standard, mail, address etc.), some created using IB some created using XCode to make the table views. I've ran the memory leak tester and it doesn't have memory leaks. It can crash at anytime on any of the views, If I flip back and forth between views and use some of the functions it closes the app.
I assume that either I am running 1) out of memory or 2) not releasing views correctly, which causes the app to close. The app is simple so I don't know how I could be out of memory and I've reviewed the code to the best of my ability for releasing the objects correctly.
So Here is my list of questions:
1) What and How to use some of the other debugging tools (or tell me what tools/files I should be looking for using)? I would like to narrow down the problem to its source.
2) What is the best practice for releasing these views? How?
3) How much memory do normal apps use? Is there a number that I should stay around? How do I verify that in the simulator? the Allocation tool?
Feel free to point me to apple docs or other stackoverflow questions that can help me.
UPDATE: It appears to only be crashing one view is used, which has a table view with custom cells... The cell are populated from a plist file... this view worked fine a few days ago, I notice that some cells do not have data from the plist file... it could be a plist file problem with not storing proper data. I'll continue to work on it.
UPDATE #2: I went back to older rev of my files, to when this particular tableView worked just fine (pre 3.0) and guess what it works just fine, I change the simulator to 3.0 with this rev of the app and bam crash on this tableView shows up. Thanks for the help so far, I'll try somethings mentioned below and let you know what I find. If you have some tips on why a tableView w/custom cells from 2.2.1 to 3.0 would start crashing, I'll take them. If I can't get anywhere I'll post the code soon. BTW, I mis-spoke above, I thought it wasn't crashing in the simulator... I was wrong it is.
Solution: thanks for the troubleshooting tips the fix was quite simple, but it's odd it didn't crash in 2.2.1... it should have crashed a long time ago for the problem, I was releasing an object one to many times in my custom cell... duh.
On the first and second generation phone's you really don't want to be going over about 20 megs of real memory usage - once you get over that you are at risk of being killed by springboard.
One of the big culprits I've seen is autoreleased memory, since the autorelease pool can hold onto memory a lot longer than you would really like - if you are using a lot of autoreleased objects that can be a potential problem. You can improve this by doing more explicit retain/release where possible and by creating local autorelease pools manually and releasing them after doing a more intensive operation with a lot of autoreleased objects.
The most effective way to keep track of real memory usage I've found so far is running a debug build on a test phone and running with Activity Monitor. That will give you a clear idea of how much memory is getting taken and held onto by your app. As well as how much is being used when it crashes on you.
You can run with Activity Monitor in Xcode on the Run menu -> Start With Performance Tool -> Activity Monitor.
One other very useful tool is the CLang Static Analyzer that you can run against your code base and can give some very helpful memory management information. As mentioned here.
One thing I would try is putting some debug messages into your didReceiveMemoryWarning method(s). That way, if you are running out of memory, you'll at least have some warning.
I'm using the Leaks Instruments feature through Xcode to (try and) find memory leaks. I still haven't figured out how to use this program. I click Leaks in the program and see memory increasing as I do various things in the simulator. I have Extended Detail pane displayed. The only thing in Extended Detail pane that references my app is main. As in the main method produced by Xcode. Everything else is UIKit, Foundations, and other SDK classes I didn't write. What am I doing wrong that nothing is showing up from my app?
Before I hit 3 minutes, there are over 100 leaks totaling 2.5k. Is this common?
I've written up a Tutorial on using Instruments to track iPhone memory leaks. I'm not sure if it will help you with what you're dealing with or not...couldn't hurt, though. :-)
http://www.streamingcolour.com/blog/tutorials/tracking-iphone-memory-leaks/
Change the view to "Extended Detail" on the instruments panel. This will show you the stack trace of each leaked object after you stop recording and select the leaked object.
You do see calls into the API, but what you are interested in is finding the last method of your application before the API calls, that is where the leak is.
A tip: turn on "gather memory contents" in the leaks view. Seeing the object values should also help finding where the problem is.
You don't want any leaks. 100 leaks is not typical (at least in my apps ;) Typical should be 0.
I'm not familiar with how to use Leaks, but you can always try running the Clang analyzer on your code to see if that'll turn anything up: http://clang.llvm.org/StaticAnalysis.html. It can often find many bugs that might lead to memory leaks.
Xcode: run -> Start with Performance Tool -> Leaks
Keep in mind that the Simulator may leak when the device will not. Ran into that once already with UITableViewController class.
Use LLVM/Clang Static Analyzer.
Note also that the leak tool is not going to show you instances where objects are over-retained and still held on to. Leaks are cases where objects that should have been let go are just hanging around with no-one to clean them up. Over retained objects are validly held onto even though you'd think they should be gone - thus the leak tool cannot point them out, since they are still referred to and there's no way to tell them apart from objects that should still be retained.
To find those, use the memory reporting tool and make sure that memory use goes down fully after you free an object. If you notice something isn't freeing memory, you can start by putting breakpoints in dealloc to see if what you expect to see released is actually getting released.
You need to look for both cases to keep a clean memory footprint.
Run -> Start with Performance Tool -> Leaks
To detect memory leaks you can use the "build and analyze" function of Xcode.
Simply select Build -> Build and Analyze in the Xcode menu.
Made a sum up of the main memory leak tools: http://bcaccinolo.wordpress.com/2010/09/15/iphone-essential-performance-tools-list/
Leaks application that can be found in Xcode: run -> Start with Performance Tool -> Leaks.
Apple’s Instruments utility that can be found in /Developer/Applications/Performance Tools.
One of the best way to find the memory leaks is Select Product-> Analyze. In the left Xcode shows in which file you have memory leaks. What are the variable causing memory leaks. This is one of the best way to find memory leaks.
The memory debugger (button just over the console, next to the view debugger) is quite useful too.
It will show you leaks, and you can check /filter easily if objects are still in memory when they shouldn't.