SocketRocket RunLoop внезапная авария
Так что наше приложение некоторое время испытывает сбои в SocketRocket. Мы получаем около 20 сбоев в день со следующей трассировкой стека:
Crashed: com.apple.root.default-overcommit-priority
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x0000000c
Thread : Crashed: com.apple.root.default-overcommit-priority
0 libsystem_platform.dylib 0x3b8ff816 spin_lock$VARIANT$mp + 1
1 CoreFoundation 0x30e2d593 CFSocketEnableCallBacks + 54
2 CFNetwork 0x30a926f9 SocketStream::securityBufferedRead_NoLock() + 212
3 CFNetwork 0x30a925f5 SocketStream::socketCallbackReadLocked(SocketStreamSignalHolder*) + 76
4 CFNetwork 0x30a90d8f SocketStream::socketCallback(__CFSocket*, unsigned long, __CFData const*, void const*) + 102
5 CFNetwork 0x30a90cf3 SocketStream::_SocketCallBack_stream(__CFSocket*, unsigned long, __CFData const*, void const*, void*) + 58
6 CoreFoundation 0x30e6a337 __CFSocketPerformV0 + 578
7 CoreFoundation 0x30e68183 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
8 CoreFoundation 0x30e67653 __CFRunLoopDoSources0 + 206
9 CoreFoundation 0x30e65e47 __CFRunLoopRun + 622
10 CoreFoundation 0x30dd0c27 CFRunLoopRunSpecific + 522
11 CoreFoundation 0x30dd0a0b CFRunLoopRunInMode + 106
12 Foundation 0x317be3db -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 254
13 Piazza 0x00110b7b -[_SRRunLoopThread main]
14 Foundation 0x31880c87 __NSThread__main__ + 1062
15 libsystem_pthread.dylib 0x3b904c1d _pthread_body + 140
16 libsystem_pthread.dylib 0x3b904b8f _pthread_start + 102
Я пытался зафиксировать это более 20 часов. Это довольно спорадично - лучший способ воспроизвести это - выйти из системы, чтобы все соединения перестали работать, а затем попытались вызвать некоторые соединения и / или подождать несколько минут. Работает примерно в 1/4 времени, через несколько минут. Тем не менее, есть журналы людей, испытывающих этот сбой, хотя все еще вошли в систему.
Что касается кода, я не могу сказать, что является причиной EXC_BAD_ACCESS, так как все записи выше 13 не имеют доступного источника, и просмотр кода ассемблера не очень меня просветил - все, что я обнаружил, это то, что ecx в процессе работы устанавливается значение 0xc, а затем spin_lock$VARIANT$mp пытается поменять некоторые регистры на вещи, расположенные в ($ecx), и происходит сбой. [_SRRunLoopThread main]единственная часть трассировки стека, для которой у меня есть источник, выглядит следующим образом:
- (void)main;
{
@autoreleasepool {
_runLoop = [NSRunLoop currentRunLoop];
dispatch_group_leave(_waitGroup);
NSTimer *timer = [[NSTimer alloc] initWithFireDate:[NSDate distantFuture] interval:0.0 target:nil selector:nil userInfo:nil repeats:NO];
[_runLoop addTimer:timer forMode:NSDefaultRunLoopMode];
int i = 0;
while ([_runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]) {
}
assert(NO);
}
}
Он падает на while линия. Я подозреваю, что что-то где-то освобождается до того, как должно, но я не уверен, что это SRWebSocket или как-то блок, который был добавлен в цикл выполнения или что. Я не совсем знаком с циклами бега.
У меня заканчиваются продуктивные вещи, чтобы понять это, и я едва достиг прогресса. Любая помощь приветствуется.
2 ответа
У меня была похожая проблема. Вероятно, потому, что объект освобожден до того, как произойдет обратный вызов.
Поэтому было бы неплохо закрыть поток в методе dealloc.
Я вижу ту же проблему в MixPanel, которая, похоже, основана на этом источнике. Предполагая, что я правильно понимаю ABI, значение CFSocketRef, которое передается в CFSocketEnableCallbacks, равно NULL, поэтому включение его для обратных вызовов read (1) завершается неудачно. Я не могу сказать вам, почему CFSocketEnableCallbacks вызывается с NULL-сокетом, но похоже, что это происходит. Может быть, это где-то нулевая слабая ссылка. Я обновлю это, когда узнаю больше.