Continuing some helpful StackOverflow debugging, I have a zombie I need to track down:
2010-08-22 10:18:51.111 AppName[106:307] *** -[CFString release]: message sent to deallocated instance 0x19f3b0
How would one find the variable name or whathaveyou for the 0x19f3b0 Zombie?
Run the Allocations instrument, and enable "NSZombie Detection" and also turn on "track release/retain". Then as you are running, when the zombie is encountered, it pops up an alert and lets you drill down to explore what code released and retained the original object.
Generally the way I do this is to hunt down the memory reference in the Object allocations instruments tool. It's tedious, but you can usually narrow it down to a few data types, of which usually only one will make sense in your context.
Of course, I only do this if I can't get good info out of the debugger.
Related
I have found few memory leaks when I am running my application. For your reference, I am sharing the screenshots of Instrument debug logs and also Xcode Debugg memory graph tool. I am not getting what is going wrong here. Please help me to resolve memory leaks.
Please help me to fix the memory shows in the image. Thank you.
I know this is an old question, but a few observations.
When you have a lot of objects that are leaking, focus on high level objects (especially your own classes). We do not care why the array was not released. We care about why the item that is keeping a strong reference to it was not released. XTubeManager and GlueTubeManager are probably good places to start searching, but I don't know what other high level objects appear in the panel on the left.
When you have leaks, it is very useful to use the “Malloc Stack Logging” feature. So edit your scheme (command+<; or “Product” » “Scheme” » “Edit”) and go to the “Diagnostics” section and temporarily turn on “Malloc Stack Logging”:
Then, when you select a leaked object, you can see where it was instantiated but using the memory inspector panel on the right:
Look for entries in that stack trace that are white (your code), as opposed to all the system items that are in gray. When you hover items in that stack trace, there is even a little arrow that lets you jump to the code in question. In my example, the leaked object was instantiated in viewDidLoad.
This will not tell you why it leaked, but you will be able to see where the object in question was instantiated in your code, and you can start your investigation from there, diagnosing why an object created at that point in your code still has lingering strong references.
Remember to turn off the “Malloc Stack Logging” feature when you are done with your diagnostics.
As an aside, when we see URLSession objects that were not released, that begs the question of whether you instantiated a URLSession object (rather than using the shared instance) and neglected to call finishTasksAndInvalidate. Ideally, you would have a single URLSession and reuse it for all network activity (or use the shared instance), but if you must instantiate sessions, make sure to invalidate them when you are done.
You do NOT need to use Instruments. That's the old way. Use Xcode itself.
See Visual Debugging with Xcode
- 24:45
Watching the video is a MUST, but the summary of the video is as such:
There are two type of memory problems. You just have to repeat a flow in your app 2-3 times to be certain the memory graph has caught it
Leaks. Xcode will annotate this with purple icon. Possible are: delegates, closures
Abandoned memory. Xcode will not annotate this. But it's still increases your memory footprint. possible examples are: A repeating timer that is never invalidated, NotificationCenter, A never ending DispatchWorkItem
For Leaks the memory graph is a loop ie two way.
For Abandoned memory the graph is NOT two way. It's just an object one that Apple categorizes as 'root path' referencing your object and never letting it go. For more on this see here
In this case, just because some tool says you’ve got a memory leak doesn’t mean you have one. The amount of data seems to be less than 1MB, that’s nothing. Your tool suspects there’s a leak because data was allocated and not released, but these are single objects. Quite possible that memory is going to be released or reused later.
Use your software for hours and check if memory usage gets larger.
Memory on mobile devices is a shared resource. Apps that manage it improperly run out of memory, crash, and suffer from drastically decreased performance.
so to fix it follow this steps
Open Xcode and build for profiling.
Launch Instruments.
Use the app, trying to reproduce as many scenarios and behaviors as possible.
Watch for leaks/memory spikes.
Hunt down the source of the memory leaks.
Fix the problem.
How do I debug and fix this error
No memory available to program now: unsafe to call malloc
Analyser doesn't show any cause.
Use instruments to check for leaks and memory loss due to retained but not leaked memory. The latter is unused memory that is still pointed to. Use Heapshot in the Allocations instrument on Instruments.
For HowTo use Heapshot to find memory creap, see: bbum blog
Basically there method is to run Instruments allocate tool, take a heapshot, run an intuition of your code and another heapshot repeating 3 or 4 times. This will indicate memory that is allocated and not released during the iterations.
To figure out the results disclose to see the individual allocations.
If you need to see where retains, releases and autoreleases occur for an object use instruments:
Run in instruments, in Allocations set "Record reference counts" on on (you have to stop recording to set the option). Cause the picker to run, stop recording, search for there ivar (datePickerView), drill down and you will be able to see where all retains, releases and autoreleases occurred.
I've been researching this throughout SO and some people said that this error is fine as long as the apps doesn't crash.
My app gets this error and after this when I try to tap on a row for a cell (calling didSelectRowAtIndexPath) it crashes. And it gives me an error UIImage sent message to deallocated message. I am guessing that this is because of the memory warning it has freed up some UIView's and therefore it crashes.
Why is this and how do I fix this? I've been debugging this for quite some time, using instruments, profiling, etc and had no luck.
I'd like to post some code, but don't know which one to post.
You have failed to retain something you cared about. From your message, I would suspect the object is a UIImage. Start by running the Static Analyzer and see if you're unretaining something obvious. Then inspect your ivars, particularly ones that are related to images. Make sure you access your ivars using accessors and not directly (except in init, the accessors themselves and dealloc). Make sure your object properties are defined with "retain".
You can use the "Zombies" instrument to help you track down which object is under-retained.
by one of your comments, it is very clear that the issue is with memory management and releasing your objects.... I suggest you to go a bit deep into your code and find out the code snippets where you are releasing you objects(or allocating them)... It can also be due to the fact that you are not at all releasing your objects after allocating and the processor trying to kill your app due to the lack of memory...And by the way, this kind of erros suck your time a lot... good luck...
I'm having a table view of data. While scrolling my table 2 or 3 times so fast, its getting crashed. My gdb is telling like
"message sent to deallocated instance...."
Anyone know how to solve this?
yes, your reference counting has errors.
to find the object, enable NSZombies. enabling NSZombies will not free your objects -- but will generate runtime errors when you attempt to message an instance which would (under normal operation) have been deallocated. from there, you can learn more about the object (e.g. its type).
Instruments also has a NSZombie mode. it is very useful to point out an object/zombie's lifetime.
for more details, see:
http://www.cocoadev.com/index.pl?NSZombieEnabled
the link also details how you can configure your executable to run with zombies enabled. this is found in the section 'Use in Xcode'.
I added NSZombieEnabled to my executable's environment in order to track down an object that I'm over releasing. What I'm finding now, is that a part of my app is crashing that never has crashed before, only when NSZombieEnabled is toggled on. The moment I disable it, no crash occurs.
I need to do forensics on my code, but what can this possibly imply? NSZombieEnabled keeps objects around that are being sent the release message. This might be causing me to crash, but should it?
Also, setting the breakpoint -[_NSZombie methodSignatureForSelector:] doesn't really give me an elaborate enough stack trace to know what's going on.
If your app crashes with NSZombieEnabled, there's a good chance it crashes with it disabled, just not as soon and not as obviously.
NSZombieEnabled keeps objects around that are being sent the release message. This might be causing me to crash, but should it?
No, it doesn't cause you to crash. What causes you to crash is sending too many release messages to an object. That's what NSZombieEnabled is for.
Also, setting the breakpoint -[_NSZombie methodSignatureForSelector:] doesn't really give me an elaborate enough stack trace to know what's going on.
Try using the ObjectAlloc preset in Instruments.
Under NSZombieEnabled, objects are not fully released, they just become zombies. This means that memory can accumulate while you run, particularly in loops where you might be generating a bunch of NSStrings or the like. Your application may be getting killed due to memory usage.
I made the mistake of turning this on and forgetting about it, then spent the longest time trying to figure out why my memory usage kept increasing when I didn't have any obvious leaks.
One possibility: It could be that you're accessing an object through an invalid pointer and lucking out that another compatible object happens to be placed there. In that case, NSZombie would prevent the object from being replaced by something compatible and instead put a Zombie in its place.