ios崩潰EXC_BAD_ACCESS KERN_INVALID_ADDRESS

MyApp在98％的時間內工作良好，但有時會顯示崩潰。它是如此隨機。ios崩潰EXC_BAD_ACCESS KERN_INVALID_ADDRESS

崩潰報告顯示以下內容。

Thread : Crashed: com.apple.main-thread 
0 libobjc.A.dylib    0x3b1ae626 objc_msgSend + 5 
1 Foundation      0x310e2381 _netServiceMonitorCallBack + 104 
2 CFNetwork      0x302ea3b5 _QueryRecordReply(_DNSServiceRef_t*, unsigned int, unsigned int, int, char const*, unsigned short, unsigned short, unsigned short, void const*, unsigned int, void*) + 324 
3 libsystem_dnssd.dylib   0x3b7289d9 handle_query_response + 168 
4 libsystem_dnssd.dylib   0x3b72773f DNSServiceProcessResult + 582 
5 CFNetwork      0x302ea3e5 _SocketCallBack_Mon(__CFSocket*, unsigned long, __CFData const*, void const*, void*) + 20 
6 CoreFoundation     0x30691189 __CFSocketPerformV0 + 580 
7 CoreFoundation     0x3068efaf __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14 
8 CoreFoundation     0x3068e477 __CFRunLoopDoSources0 + 206 
9 CoreFoundation     0x3068cc67 __CFRunLoopRun + 630 
10 CoreFoundation     0x305f7729 CFRunLoopRunSpecific + 524 
11 CoreFoundation     0x305f750b CFRunLoopRunInMode + 106 
12 GraphicsServices    0x355336d3 GSEventRunModal + 138 
13 UIKit       0x32f58871 UIApplicationMain + 1136 
14 MyApp       0x0013f813 main (main.m:16)

所有這些看起來都是內部方法。我確實在運行iOS 7.1.2的iPad 4上遇到這些崩潰。我怎麼能找到它。所有幫助讚賞。

來源

2014-09-05 Sj.

顯示的崩潰報告的頂部，請。尤其是例外代碼。它是'0xbadfood'嗎？ – orkoden 2014-09-05 10:14:52

沒有異常代碼是0xf000000c，0x0000000f。這兩個崩潰都有相同的堆棧。 – 2014-09-05 10:27:11

使用ExceptionHandler，請在這裏查看我的答案：http://stackoverflow.com/questions/10501358/objective-c-getting-line-number-or-full-stack-trace-from-debugger-error/25551171#25551171 – 2014-09-05 11:25:30

由於內存泄漏而發生此崩潰。當任何變量或對象試圖訪問受限制的內存時，就會發生這種崩潰。

來源

2014-09-05 10:11:36 Indrajeet

這可能是由於將消息發送給已釋放的對象。但看着堆棧跟蹤，我不明白它可能出錯了，並且項目完全在ARC中。 – 2014-09-05 10:34:25

使用任何塊？ – stevesliva 2014-09-06 04:30:46

@ stevesliva爲什麼塊會成爲問題？[我正在使用它們，並且出現類似的錯誤] – ripegooseberry 2015-04-22 09:36:31

這是一個老問題，但EXC_BAD_ACCESS KERN_INVALID_ADDRESS崩潰不是由於內存泄漏，而是由於嘗試訪問釋放對象。因爲解除分配的對象的內存現在可能已被另一個不同類型的對象佔用，所以崩潰堆棧中的最後一行可能是錯誤的，因爲它不是您編程的執行路徑的一部分，所以通常我們需要查找跟蹤一點點。然而@Sj發佈的堆棧跟蹤基本上只包含系統調用，所以它確實很難。如果這是在調試會話中生成的，那麼添加「所有異常」斷點可能有助於生成更多信息的堆棧跟蹤。

來源

2017-06-15 15:14:05 CodePlumber

謝謝指出。是的，這不是由於內存泄漏。史蒂夫斯利瓦添加了一條評論幫助。這是由於塊和物體過早釋放。這就是爲什麼堆棧跟蹤也不清楚。 – 2017-08-03 15:35:24

-2

EXC_BAD_ACCESS KERN_INVALID_ADDRESS碰撞不是由於內存泄漏，但由於嘗試訪問解除分配的對象。

例如：如果使用__weak typeof(self) weakSelf = self;，你訪問它裏面塊之前，對象已被釋放，你會擁有崩潰。原因 - 訪問錯誤的內存地址，因爲對象被釋放。

爲了防止在塊內使用__strong typeof(self) strongSelf = self;。 Nil值將不崩潰妥善處理

注：使用了快下班了此代碼示例。

#define weakify(var) __weak typeof(var) AHKWeak_##var = var; 

#define strongify(var) \ 
_Pragma("clang diagnostic push") \ 
_Pragma("clang diagnostic ignored \"-Wshadow\"") \ 
__strong typeof(var) var = AHKWeak_##var; \ 
_Pragma("clang diagnostic pop")

用例：

weakify(self); // Remove retain cycle 
[self someFunctionWithBlock:^{ 
    strongify(self); // Make reference to address valid 

}];

來源

2017-08-03 10:06:26 akaDuality

這是不正確的;發送一個'nil' weakSelf就像在ObjC中發送任何其他'nil'一樣，這是一個無用的操作並且很好。如果你要發送多條消息，你只需要'強化'弱引用，以確保它不會被部分解除分配。 – buildsucceeded 2017-08-30 09:17:27

也許我沒有清楚地描述過，但是你重複我的想法，我同意你的看法。 – akaDuality 2017-08-31 09:49:46

ios崩潰EXC_BAD_ACCESS KERN_INVALID_ADDRESS

回答

相關問題