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'.
Related
An error is caught, using Zombie
CFString Foundation Library
caller {NSPlaceholderMutableString int] Malloc
CFString Foundation Library
caller {NSPlaceholderString initWithFormat:locale} Zombie
well it didn't drop to where I declared. I have no idea where that NSMutablestring is called and which variable it is
Instruments provides an option to record reference counts -- ensure it's enabled.
Run your app and reproduce the issue.
When Instruments halts the program due to messaging a zombie, it will tell you the address of the zombie.
You then locate the address in the list of allocations and view the location it was created, as well as all its ref count ops.
It takes about 2 minutes to spot an issue once you get the hang of it, and can reproduce the problem. Good luck.
Also, 0x8badf00d has recommended "session 311 Advanced Memory analysis with Instruments." below. I've not watched it personally, but it sounds like it would be a great session on the subject.
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 am testing an EXE_BAD_ACCESS error. I have set NSZombieEnabled, MallocStackLogging, MallocStackLoggingNoCompact to YES. now in the debugger I get this message when I run my app in the debug mode from the device I could see this:
iota(3586) malloc: recording malloc stacks to disk using standard recorder
iota(3586) malloc: stack logs being written into /private/var/mobile/Applications/8E21A85B-369E-4487-962B-1550E56602DC/tmp/stack-logs.3586.iota.index
iota(3586) malloc: Please issue: cp /private/var/mobile/Applications/8E21A85B-369E-4487-962B-1550E56602DC/tmp/stack-logs.3586.iota.suRQjy.link /tmp/
and when I am about to hit the error I get,
2011-02-14 14:29:44.350 iota[3586:307] *** -[CFString autorelease]: message sent to deallocated instance 0x81eab70
Finally when I give the command in debugger to see the stack trace
(gdb) shell malloc_history 3586 0x81eab70
I get
malloc_history cannot examine process 3586 because the process does not exist.
Can anyone tell me what I am doing wrong, before the error is about the occur , I set
set env MallocStackLogging 1 in the debugger too
Thanks in Advance
It looks like you are releasing an NSString that you don't own. If you get a string from one of the class methods they are delivered as autoreleased objects, so unless you retain it, you shouldn't release it.
For a full explination check out the Memory Management Programming Guidelines.
The memory may remain allocated while you are using it, or be released but coincidentally still valid, during testing, but is more likely to be released and show up as bad access errors when running on the device.
The best way to track these things down, and a good idea anyway (even if there are no apparent problems) is to run the app in the Instruments tool, especially with the Leaks option.
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.
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.