EXC_BAD_ACCESS error tracing the origin
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.
精彩评论