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).
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 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?
Right now my app should only supports Portrait. On Summary/Supported Device Orientations I have only selected Portrait so I'm hoping that my app will not rotate. I was testing the app on a device and suddenly I'm getting the following error randomly:
[UIButtonContent deviceOrientationDidChange:]: unrecognized selector sent to instance
It happens when I rotate the device SOMETIMES, is not consistent, and is not always over UIBUttonContent. I supposed that if I only select Portrait, deviceOrientationDidChange should not be called or should be ignored.
Other times my app crashes with an EXC_BAD_ACCESS (code=1, address=something) but it happens when I rotate the device so I'm guessing that both errors are related.
I don't know what to do with this, it's hard to debug because I don't have feedback, the All Exceptions Breakpoint is not being called, so I don't know where and exactly why this is happening. Any idea on how to debug this is welcome.
These are the classic signs of a memory management error. You have over-released some object and it has been deallocated while something else still references it. Later, something messages it. In some cases a new object has taken its place, but that object doesn't understand the messages it's receiving. In other cases, there's no valid object and you get a crash.
Edited to second the advice to use the Zombies instrument to find the over-release.
Do you have a class that should be called with deviceOrientationDidChange:? When this happens, it usually means that you have a dangling reference to a deallocated object. You should try profiling your app with Instruments in "Zombies" mode.
I solved this issue a long time ago, but I think is good to share what actually helped me on this case.
After trying everything with no results with Instruments I started debugging old-school. I had an idea of "where" the error was so I just commented all the code on that section. I was right, the bug just disappeared along with some functionalities. After that I made "binary uncommenting" (uncomment one half) till I got the bug line. It was a third party library, I had an object that was not being released properly.
I am attempting to debug an issue where an object is released too many times and is then deallocated by the event loop. The next time I try to read from the object, the application crashes with EXC_BAD_ACCESS.
To debug, I am enabling NSZombies and then using the Zombies profile with Instruments. I then reach the point where my app crashes and Instruments informs me about a message being sent to a deallocated instance. So far, so good.
It does a very good job of showing me where libraries such as UIKit are releasing and retaining the pointer to my object, but it does not show me where my own code is doing this. It is also not displaying the true reference count. By the time that Instruments says that the reference count is 1, the reference count is actually 8 according to printing out the reference count in gdb.
I have investigated the possibility that Instruments is somehow filtering the output but it would appear that I really am recording every release and retain event. It absolutely must be something in my application because my view controller is instantly deallocated after displaying, meaning that attempting to do anything that would send a message to the controller would crash it.
After placing a breakpoint in the dealloc method, I found that my object is indeed being deallocated by the event loop, so this is not a case of a rogue call to dealloc by something else.
You can't rely on reference count as Apple's Framework classes may hold their own references to your objects. The reference count is meaningless for debugging.
Click in the (i) left of the Allocations-Graph
Set "Record reference counts"
You are done ;)
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).