SocketRocket RunLoop crash esporádico

Por lo tanto, nuestra aplicación ha estado experimentando fallas durante un time en SocketRocket. Obtenemos alnetworkingedor de 20 lockings al día, con la siguiente traza de stack:

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::securityBuffenetworkingRead_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 

He intentado resolverlo durante más de 20 horas. Es bastante esporádico, la mejor manera de reproducirlo es cerrar session, por lo que todas las conexiones fallan, y luego tratar de incitar algunas conexiones y / o esperar varios minutos. Funciona aproximadamente 1/4 del time, luego de unos minutos. Sin embargo, hay loggings de personas que experimentaron este locking mientras aún estaban conectados.

En cuanto al código, no puedo decir qué está causando el EXC_BAD_ACCESS, ya que todas las inputs anteriores a 13 no tienen fuente disponible, y mirar el código de ensamblaje realmente no me ha iluminado mucho, todo lo que he descubierto es que ecx se pone a 0xc en el curso de las cosas, y luego spin_lock $ VARIANT $ mp intenta intercambiar algo de logging para cosas ubicadas en ($ ecx), y se bloquea. [_SRRunLoopThread main] , la única parte del rastreo de stack para la que tengo origen es la siguiente:

 - (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); } } 

Se cuelga en la línea while . Sospecho que algo, en algún lugar, se está desasignando antes de que se supone que debe hacerlo, pero no estoy seguro si es un SRWebSocket o de alguna manera un bloque que se agregó al ciclo de ejecución o qué. No estoy totalmente familiarizado con los loops de ejecución.

Me estoy quedando sin cosas productivas para hacer para resolver esto, y no he hecho ningún progreso. Cualquier ayuda es apreciada.

Tuve un problema similar. Es probable que sea porque el object se desasigna antes de que ocurra la callback.

Entonces, podría ser una buena idea cerrar la transmisión en el método dealloc.

Estoy viendo el mismo problema en MixPanel, que parece estar basado en esa fuente. Suponiendo que entiendo correctamente el ABI, el valor CFSocketRef que se transfiere a CFSocketEnableCallbacks es NULL, por lo que falla la habilitación de las devoluciones de llamada de lectura (1). No puedo decirte por qué se invoca CFSocketEnableCallbacks con un socket NULL, pero eso es lo que está sucediendo. Quizás sea un problema de reference débil a cero en alguna parte. Actualizaré esto cuando sepa más.