I am new to ios development. I am having a very serious issue now. My application is almost complete but it crashes very often due to memory warning. The memory warning is received whenever I present a new view controller on the top of the existing view controller. The custom view class adds UIWebView to its view when the new view controller is loaded.
I tried to debug the memory allocation with instruments but do not have any idea on how the memory is being allocated. The screenshot of the heapshot analysis shows bunch of non-objects as in the figure below and when I see the stack trace it points to adding the webview.
Please suggest me how I have to debug. What does these non-objects point to and how should I deal with them. I thank you for your suggestion and help in advance.
Non-object allocations are almost always used as backing stores within objects. I.e. an NSMutableArray will often be backed by several malloc()'d buffers that show up in non-object allocations in instruments.
Unless the non-objects are the only thing showing up as allocations in Instruments, you can ignore them.
Instead, focus on allocations of a specific type. Anything else in that Heapshot iteration? Looks like there is a CardScrollView in that backtrace on the right. Are they going away correctly?
Related
How can I track down abandoned memory if in Xcode Instruments don´t show my custom classes?
So I can see the heap is growing after I perform an action with my app (open a view and go back to the previous in my case) and I could fix some memory issues before by tracking down my mistakes in my code.
Now however, I only see things like in Generation N (= Heapshot N), non-object and I don´t know any more how I can fix the leaks. The responsible caller (not seen in the screenshots) also show no own classes/objects.
Edit
The Showing View is a UIWebView. I searched the web and found rumors that UIWebView doesnt properly releasing data. Could that be the issue? I can´t find any solution.
UIWebView is notorious for causing memory issues.
Make sure you set the UIWebView object's delegate property to nil if you assigned an object to it as documented in the class reference. You can do this in dealloc.
Cleanup the web view in viewWillDisappear:animated: by stopping URL loading with a call to stopLoading and/or setting the HTML string to nil by calling loadHTMLString:baseURL: to workaround any memory being held.
I have a cocos2d project. Everything works fine, except when I am replacing a scene.
When replacing the scene, I receive the message "Message sent to deallocated instance" followed by a memory address.
The way my project is structured, most CCNodes are children of the main "Scene" which is replaced. These nodes are also stored in various arrays for iterating among similar objects etc.
I can't imagine how I am over-releasing any of the objects, since adding to arrays should increase the reference count, as should adding to the main scene.
Should I do something about this? What happens if I ignore it? (Turn NSZombies off?) The error pops up when objects are being deallocated, so it should just mean that the object is already release right?
Any suggestions on how I can figure out what I am doing wrong?
You need to fix it, as it will cause crashes once you turn NSZombies off. Somewhere in your code your memory management isn't correct. Xcode can help you find it: run Product -> Analyze (Shift-Command-B).
i've a navigation controller with several viewController and tableViewController.
I'm using all autorelease objects, the problem is that when i push a new view and i use it, memory from Instrumets increase of a bigger value of memory released when i come back in the navigationController. There's not leak warning, when i return to the view then, memory will not increase again, it's like if was all in cache.
I've tried also using objects own by me, with alloc....and release but the story is the same. Is it normal?
UIViewControllers (or to be exact, views/resources/xibs associated with them) are interesting since iOS will hold on to the resources in memory and unload them as required. This is why often the dealloc method will seem like it's never called. However don't worry, if you did proper memory management, your controllers and resources will be freed up as required - if there's a low memory warning sent to your app, all the views that are hidden or have been popped, will be unloaded and dealloc'ed.
Try testing your app again, just like you did before, but this time emulate low memory usage (can be done in simulator from the Hardware menu), then see if memory usage drops due to your controllers being freed up by the system
I'm trying to understand the Leaks Instrument Tool that Xcode4 provides us. The screenshot below shows me a couple of leaks (I think). I was wondering how to read the Leaked object and diagnose where the leak is coming from. Anyone have any suggestions to what [NSPlaceholderMutableString ...] is? I don't have this declared anywhere in the program itself.
NSPlaceholderMutableString is a private subclass of NSString, which is a class cluster.
See that small little arrow in a circle? Click it couple of times and you'll get to the code (if it's yours). (Last time there will be no arrow, just double-click the row)
Read carefully what the titles of the columns and navigation bar say. All info you needed is there ;)
I'm currently hunting down a memory leak in my app for iPhone. I'm using Instruments to track down the code that is causing the leak (becoming more and more a friend of Instruments!). Now Instruments show two lines: one in dark blue (row 146) and one in a lighter blue (150). From some trial and error I get that they are connected somehow, but not good enough at Objective-C and Memory Management yet to really understand how.
Does anyone know why different colors are used and what could be my problem?
I have tried to release numberForArray but the the app crashes when showing the last line in a picker view.
All ideas appreciated!
(Posting this I also realize that line 139 is redundant! Se there, already an improvement ;-)
Ok, lets take a look at the object allocation/ownership behavior of this code...
numberForArray is assigned the result of -NSString stringWithFormat:, which is an auto-released object. That means that you do not want to release it (as you discovered).
That object is then added to the glucoseLoader NSMutableArray, which will retain it. You loop 100 times, creating 100 objects and adding them to glucoseLoader. When glucoseLoader is released, at line 154, it will also release all the objects added to it.
But wait, there's more: firstComponentRange is created from glucoseLoader using -NSArray initWithArray:. When you do that, all the elements of the source array are added to the destination, which will retain them again.
So, when/how do you release firstComponentRange?
Instruments is telling you that firstComponentRange is not being released (a small leak). Since the array retains its contents, you ate thus also leaking 100 NSString instances, allocated at the line indicated with a darker band (a more significant leak).