How to debug EXC_BAD_ACCESS
2011-01-27 15:32
501 查看
Click on the "Targets" tab, open "Executables" and select the app (In XCode 2.0, double-click the executable in the file tree and select the arguments tab to enter environment variables). In the executable settings, add the following environment variables and set their values to "YES" (without the quotes):
You may also want the following environment variable set to YES:
With NSZombieEnabled, Cocoa sets an object's isa pointer to the NSZombie class when its retain count drops to zero instead of deallocating it. Then when you send a message to an NSZombie object (i.e., you're accessing freed data), it raises an exception and tells you where the object lives:
Since you have MallocStackLogging turned on, you can now run "malloc_history <pid> <address>" to see the stack trace when the object was allocated:
if you run under gdb, you may enter:
And there it is: the double-released object was allocated with [NSData dataWithBytes:length:] in the function main()!
I love you, Cocoa!
NSDebugEnabled NSZombieEnabled MallocStackLogging
You may also want the following environment variable set to YES:
MallocStackLoggingNoCompact
With NSZombieEnabled, Cocoa sets an object's isa pointer to the NSZombie class when its retain count drops to zero instead of deallocating it. Then when you send a message to an NSZombie object (i.e., you're accessing freed data), it raises an exception and tells you where the object lives:
2003-03-18 13:01:38.644 autoreleasebug[3939] *** *** Selector 'release' sent to dealloced instance 0xa4e10 of class NSConcreteData.
Since you have MallocStackLogging turned on, you can now run "malloc_history <pid> <address>" to see the stack trace when the object was allocated:
[dave@host193 Frameworks]$ malloc_history 3939 0xa4e10 Call [2] [arg=32]: thread_a0000dec |0x1000 | start | _start | main | +[NSData dataWithBytes:length:] | NSAllocateObject | object_getIndexedIvars | malloc_zone_calloc
if you run under gdb, you may enter:
(gdb) shell malloc_history 3939 0xa4e10
And there it is: the double-released object was allocated with [NSData dataWithBytes:length:] in the function main()!
I love you, Cocoa!
相关文章推荐
- how to debug EXC_BAD_ACCESS on iPhone
- how to debug EXC_BAD_ACCESS on iPhone
- how to debug EXC_BAD_ACCESS on iPhone
- how to debug EXC_BAD_ACCESS on iPhone
- how to debug EXC_BAD_ACCESS on iPhone
- iOS内存错误EXC_BAD_ACCESS的解决方法(message sent to deallocated instance)
- iOS内存错误EXC_BAD_ACCESS的解决方法(message sent to deallocated instance)
- EXC_BAD_ACCESS的Debug技巧
- iOS内存错误EXC_BAD_ACCESS的解决办法(message sent to deallocated instance)
- Xcode调试之exc_bad_access以及 message sent to deallocated instance
- AsyncSocket EXC_BAD_ACCESS unrecognized selector sent to instance:0x6000001908e0
- iOS内存错误EXC_BAD_ACCESS的解决方法(message sent to deallocated instance)
- ios开发笔记----exc_bad_access(code=1, address=0x789870)野指针错误,假死debug状态
- EXC_BAD_ACCESS and char pointer to float pointer cast
- iOS内存错误EXC_BAD_ACCESS的解决方法(message sent to deallocated instance)
- iOS内存错误EXC_BAD_ACCESS的解决方法(message sent to deallocated instance)
- iOS内存错误EXC_BAD_ACCESS的解决方法(message sent to deallocated instance)
- EXC_BAD_ACCESS at lauch for EAGLContext renderbufferStorage: fromDrawable: in Cocos2d app whie debug
- message sent to deallocated instance EXC_BAD_ACCESS 获取更多调试信息
- iOS内存错误EXC_BAD_ACCESS的解决方法(message sent to deallocated instance)