iphone 调试 EXC_BAD_ACCESS 小记
本文摘自：http://www.cnblogs.com/shenyunjun420/archive/2011/08/04/2127464.html
第一次遇到 EXC_BAD_ACCESS , 然后程序崩溃,没有任何调试信息
上网一查是这样解释的
向已经释放的对象发送消息时会出现EXC_BAD_ACCESS。当出现错误时，通常会调用堆栈信息，特别是在多线程的情况下。
其实就是使用了野指针.
于是,我就按照教程(http://www.codza.com/how-to-debug-exc_bad_access-on-iphone) 在Xcode中打开executables
然后，打开信息面板中的Arguments面板
然后添加参数 NSZombiEnabled=YES, 这个参数值可以让GDB在发现使用已经释放的对象时给出一个有用信息
(Zombie 想起了植物大战僵尸....)
再次运行,GDB给出了出错消息 2011-01-11 01:00:00.299 VDic[342:20b] *** -[FMResultSet release]: message sent to deallocated instance 0x3d30f70
至此,我知道了是FMResultSet 释放过度
但是是哪个地方释放过度却不甚清楚
于是把 objc_exception_throw 和 -[NSException raise] 加入了断点列表
再次运行,发现错误定位到main函数...汗...这个还是太不精确了
为什么main函数是错误位置呢? 我突然想到了main 函数里有个内存池来维护使用自动回收机制的对象
那么错误定位到main 可能就是这个位置出了问题
int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
进一步的回忆Fundation 框架的内存管理机制, 我很显然是在某个地方release了本来应该自动回收的FMResultSet对象
这样我就能够定位一些位置了, 查找了下, 果然....
+ (NSMutableArray *) select: (NSString *) sql;
{
NSMutableArray *arr = [[NSMutableArray alloc] init];
FMResultSet *rs = [db executeQuery:sql];
while ([rs next]) {
[arr addObject:[rs resultDict]];
}
[rs close];
[rs release];
return arr;
}
rs是其它对象函数返回的结果,初始时引用计数为1,并被投入到自动释放池中
而我画蛇添足的release 则是一切灾难的根源,阿门
去调此句果然运行通过了.
请大声朗读以下 Cocoa Fundation内存释放原则
1. 通过分配或复制创建的对象保持计数1
2. 假设任何别的方法获取的对象保持计数1,而且在自动释放池中. 要想在当前执行范围外使用该对象,就必须保持它
3. 向集合添加对象时它就被保持,从集合移除对象时就被释放.释放集合对象会释放该集合中的所有对象
4. 确保有多少alloc,copy,mutableCopy或retain消息就有多少release或autorelease消息发送给该对象. 换句话说,确保你的代码平衡
5. 在访问方法设置属性,先保持,再释放 (ztime: 现在有@propperty , @synthesize 两个指令自动创建此代码)
6. 用@"..."结构创建的NSString对象是常量.发送release或retain并无效果
总体而言,Cocoa Fundation的内存管理还是非常简单清晰的,
MS的COM对象生存期管理一样是智能指针:)
上网一查是这样解释的
向已经释放的对象发送消息时会出现EXC_BAD_ACCESS。当出现错误时，通常会调用堆栈信息，特别是在多线程的情况下。
其实就是使用了野指针.
于是,我就按照教程(http://www.codza.com/how-to-debug-exc_bad_access-on-iphone) 在Xcode中打开executables
然后，打开信息面板中的Arguments面板
然后添加参数 NSZombiEnabled=YES, 这个参数值可以让GDB在发现使用已经释放的对象时给出一个有用信息
(Zombie 想起了植物大战僵尸....)
再次运行,GDB给出了出错消息 2011-01-11 01:00:00.299 VDic[342:20b] *** -[FMResultSet release]: message sent to deallocated instance 0x3d30f70
至此,我知道了是FMResultSet 释放过度
但是是哪个地方释放过度却不甚清楚
于是把 objc_exception_throw 和 -[NSException raise] 加入了断点列表
再次运行,发现错误定位到main函数...汗...这个还是太不精确了
为什么main函数是错误位置呢? 我突然想到了main 函数里有个内存池来维护使用自动回收机制的对象
那么错误定位到main 可能就是这个位置出了问题
int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
进一步的回忆Fundation 框架的内存管理机制, 我很显然是在某个地方release了本来应该自动回收的FMResultSet对象
这样我就能够定位一些位置了, 查找了下, 果然....
+ (NSMutableArray *) select: (NSString *) sql;
{
NSMutableArray *arr = [[NSMutableArray alloc] init];
FMResultSet *rs = [db executeQuery:sql];
while ([rs next]) {
[arr addObject:[rs resultDict]];
}
[rs close];
[rs release];
return arr;
}
rs是其它对象函数返回的结果,初始时引用计数为1,并被投入到自动释放池中
而我画蛇添足的release 则是一切灾难的根源,阿门
去调此句果然运行通过了.
请大声朗读以下 Cocoa Fundation内存释放原则
1. 通过分配或复制创建的对象保持计数1
2. 假设任何别的方法获取的对象保持计数1,而且在自动释放池中. 要想在当前执行范围外使用该对象,就必须保持它
3. 向集合添加对象时它就被保持,从集合移除对象时就被释放.释放集合对象会释放该集合中的所有对象
4. 确保有多少alloc,copy,mutableCopy或retain消息就有多少release或autorelease消息发送给该对象. 换句话说,确保你的代码平衡
5. 在访问方法设置属性,先保持,再释放 (ztime: 现在有@propperty , @synthesize 两个指令自动创建此代码)
6. 用@"..."结构创建的NSString对象是常量.发送release或retain并无效果
总体而言,Cocoa Fundation的内存管理还是非常简单清晰的,
MS的COM对象生存期管理一样是智能指针:)
对象释放后通常要把指针设为nil
