EXD_BAD_ACCEEE錯誤，acc.exe應用程式錯誤

EXD_BAD_ACCEEE錯誤，acc.exe應用程式錯誤

iOS開發過程中，普通的bug通常較容易定位問題所在，但是，EXD_BAD_ACCEEE問題卻比較不易尋找問題。本文記錄下解決EXD_BAD_ACCEEE問題的過程。首先說一下 EXC_BAD_ACCESS 這個錯誤，可以這麼說，90%的錯誤來源在於對一個已經釋放的對象進行release操作。

1. 重寫object的respondsToSelector方法，現實出現EXEC_BAD_ACCESS前訪問的最後一個object

有時程式崩潰根本不知錯誤發生在什麼地方。比如程式出現EXEC_BAD_ACCESS的時候，雖然大部分情況使用設定 NSZombieEnabled環境變數可以協助你找到問題的所在，但少數情況下，即使設定了NSZombieEnabled環境變數，還是不知道程式崩 潰在什麼地方。那麼就需要使用下列代碼進行協助了：

 #ifdef _FOR_DEBUG_  -(BOOL) respondsToSelector:(SEL)aSelector {      printf("SELECTOR: %s\n", [NSStringFromSelector(aSelector) UTF8String]);      return [super respondsToSelector:aSelector];  }  #endif  

你需要在每個object的.m或者.mm檔案中加入上面代碼，並且在 other c flags中加入-D _FOR_DEBUG_（記住請只在Debug Configuration下加入此標記）。這樣當你程式崩潰時，Xcode的console上就會準確地記錄了最後啟動並執行object的方法。

2. 通過NSZombieEnabled

相信很多人都知道通過NSZombies來協助調試出現EXC_BAD_ACCESS的情況,但有時還是找不到需要的資訊,那麼應該怎麼辦呢?

下面通過一個例子來說明.下面是hello world的代碼:

NSString* hello = [NSString stringWithFormat:@"Hello world"];  NSLog(@"What you say is %@",hello);  [hello release]; 

運行後出現EXC_BAD_ACCESS錯誤.但沒有其他任何提示,這時 候通過右擊executables下的應用程式名稱,選擇get info後,在arguments下輸入環境變數(NSZombieEnabled,MallocStackLogging)

再次運行後程式crash,

 

這次可以看到問題是”message sent to dealloced object”了,但具體是哪個語句引起的還並不知道,於是需要在gdb上輸入以下語句:

　　　　shell malloc_history pid address 

那麼pid和address是什麼呢?再看下crash的圖片結合一下我以下使用的命令,你應該很快就可以判定pid和address是從哪裡來的了,我的命令是:

　　　　shell malloc_history 596 0×5f3ef80 

再次運行,程式crash時會出現大量的stack trace資訊,如是與本程式相關的:

根據這些資訊大家就可以找到問題出現在[BadAccessViewController viewDidLoad] 中與 +[NSString stringWithFormat:] 有關的地方.

最後大家記得把環境變數NSZombieEnabled,MallocStackLogging刪除或設定為NO,因為它們會使得記憶體不會被真實釋放.

3、設定全域斷點快速定位問題代碼所在行

XCode調試技巧–設定全域斷點快速定位問題代碼所在行

以上轉載至：http://mobile.51cto.com/iphone-279455.htm

 

註：stackoverflow上的回答： http://stackoverflow.com/questions/327082/exc-bad-access-signal-received