2014-09-05 9 views
25

MyApp는 98 %의 시간 동안 잘 작동하지만 때로는 충돌이 발생합니다. 그리고 너무 무작위.ios crash 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에서 이러한 충돌이 발생합니다. 어떻게 못을 박을 수 있습니까? 모든 도움을 주셨습니다.

+1

은 충돌 보고서의 상단을보기 바랍니다. 특히 예외 코드. '0xbadfood'입니까? – orkoden

+0

예외 코드는 0xf000000c, 0x0000000f가 아닙니다. 두 충돌 모두 동일한 스택을가집니다. –

+0

ExceptionHandler를 사용하여 내 대답을 확인하십시오. http://stackoverflow.com/questions/10501358/objective-c-getting-line-number-or-full-stack-trace-from-debugger-error/25551171#25551171 –

답변

20

메모리 누수로 인해이 충돌이 발생합니다. 변수 또는 객체가 제한된 메모리에 액세스하려고하면이 충돌이 발생합니다.

+5

이미 릴리스 된 개체로 메시지를 보내는 것이 원인 일 수 있습니다. 그러나 스택 추적을 보면 어디에서 잘못되었을 지 모르고 프로젝트가 완전히 ARC에서 이해할 수 있습니다. –

+2

블록을 사용하고 있습니까? – stevesliva

+1

@stevesliva 여기 왜 블록이 문제가됩니까?[나는 그들을 사용하고 있는데 비슷한 오류가 발생했습니다] – ripegooseberry

11

이것은 오래된 질문이지만 EXC_BAD_ACCESS KERN_INVALID_ADDRESS 충돌은 메모리 누수로 인한 것이 아니라 할당 취소 된 개체에 대한 액세스 시도 때문입니다. 할당 취소 된 객체의 메모리가 이제는 다른 유형의 다른 객체에 의해 점유 될 수 있기 때문에 충돌 스택의 마지막 행은 프로그래밍 된 실행 경로의 일부가 아니기 때문에 잘못 인도 될 수 있습니다. 따라서 일반적으로 추적을 찾아야합니다 조금. 그러나 @Sj에 의해 게시 된 스택 추적은 기본적으로 시스템 호출만으로 이루어 지므로 정말 어렵습니다. 이것이 디버그 세션에서 생성 된 경우 "모든 예외"중단 점을 추가하면보다 유익한 스택 추적을 생성하는 데 도움이 될 수 있습니다.

+0

지적 해 주셔서 감사합니다. 그래, 메모리 누출 때문이 아니야. stevesliva는 도움이되는 덧글을 추가했습니다. 그것은 블록들과 조기에 공개 된 물체 때문이었습니다. 그래서 스택 추적 또한 명확하지 않습니다. –

-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 

}]; 
+0

올바르지 않습니다. 'nil' weakfelf를 메시징하는 것은 ObjC의 다른'nil' 메시지와 거의 같습니다. 약한 참조가 여러 메시지를 보내려는 경우, 약한 참조를 중간에 할당 취소하지 않도록 '강화'해야합니다. – buildsucceeded

+0

아마도 분명히 설명하지 않았지만 내 생각을 되풀이합니다. 나는 당신에게 동의합니다. – akaDuality