iOS crash EXC BAD ACCESS KERN недопустимый адрес

MyApp работает хорошо в 98% случаев, но иногда он показывает сбой. И это так случайно.

отчет о сбое показывает следующее.

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)

все эти методы выглядят внутренними. Я испытываю эти сбои на iPad 4 под управлением iOS 7.1.2. Как я могу это выяснить? Все помогает оценить.

32
cfnetwork ios ios7.1 objective-c

3 ответов

этот сбой происходит из-за оборванных указатель. Когда любая переменная или объект пытается получить доступ к объекту, который уже был освобожден, происходит сбой.

18

Это старый вопрос, но сбой EXC_BAD_ACCESS KERN_INVALID_ADDRESS не из-за утечки памяти, а из-за попытки доступа к освобожденному объекту. Поскольку память освобожденного объекта, возможно, теперь занята другим объектом другого типа, последняя строка в стеке сбоев может быть неправильной, потому что она на самом деле не является частью запрограммированного пути выполнения, поэтому обычно нам нужно немного посмотреть трассировку. Однако трассировка стека, опубликованная @Sj, состоит в основном только системных вызовов, так что это действительно трудно. Если это создается в сеансе отладки, добавление точки останова "все исключения" может помочь создать более информативную трассировку стека.

30

exc_bad_access kern_invalid_address сбой не из-за утечки памяти, но из-за попытки получить доступ к освобожденному объекту.

пример: если вы используете __weak typeof(self) weakSelf = self; и объект был выпущен, прежде чем вы получите доступ к нему внутри блока, вы получите сбой. Причина-доступ к неправильному адресу памяти, потому что объект был освобожден.

чтобы предотвратить это использование __strong typeof(self) strongSelf = self; внутри блока. Nil значение будет правильно обработано без crash

Примечание: используйте этот пример кода для быстрой работы.

#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

}];
-3