开发者

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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜