調試 EXC_BAD_ACCESS 小記

第一次遇到 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物件存留期管理一樣是智能指標:)

 對象釋放後通常要把指標設為nil