en KSThread.c, EXC_BAD_ACCESS
-->if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
{
KSLOG_TRACE("Este subproceso no tiene una cola de envío adjunta: %p", subproceso);
falso retorno;
}
Bloqueado: subproceso
0 KSCrash 0x10056738c ksthread_getQueueName (KSThread.c:82)
1 KSCrash 0x100567370 ksthread_getQueueName (KSThread.c:75)
2 KSCrash 0x10053f6c8 monitorCachedData (KSCrashCachedData.c:84)
3 libsystem_pthread.dylib 0x18d021850
4 libsystem_pthread.dylib 0x18d021760 _pthread_start + 282
5 libsystem_pthread.dylib 0x18d01ed94 thread_start + 4
Este es mi accidente n. ° 1 ahora, ¿alguien puede ver este problema? o debo hacer mi propia rama de este proyecto?
He estado demasiado ocupado con el trabajo durante las últimas semanas (nuevo trabajo). Si alguien hace un PR, ¡generalmente soy rápido para fusionarlos!
¡Bien gracias!
@ ferrous777 ¿algo de suerte? Yo también estoy viendo este accidente.
No sé cómo reproducir este problema, pero parece que el dispatch_queue_ptr
que obtenemos de thread_identifier_info_t.dispatch_qaddr
apunta a una ubicación falsa. Acabo de enviar un PR que agrega KSThread_Test nuevamente (https://github.com/kstenerud/KSCrash/pull/221) pero no pude averiguar cómo agregar una prueba que nos diera este comportamiento de puntero falso.
e8977a426ab3ef83939a1929c9c4743ae314bcd1 debería solucionar este problema. No estaba buscando un puntero válido antes de eliminar la referencia. Esto también está etiquetado como 1.15.5, y estoy empujando a cocoapods.
@kstenerud Hola amigo, revisé tu confirmación
pero para esta línea de código:
dispatch_queue_t* dispatch_queue_ptr = (dispatch_queue_t*)idInfo->dispatch_qaddr;
¿No te dieron errores al construir?
Obtuve el mismo error/bloqueo, versión:
- KSCrash/Core (1.15.18):
- KSCrash/Reporting/Filters/Basic
- KSCrash/Recording (1.15.18):
- KSCrash/Recording/Tools (= 1.15.18)
- KSCrash/Recording/Tools (1.15.18)
- KSCrash/Reporting/Filters/Base (1.15.18):
- KSCrash/Recording
- KSCrash/Reporting/Filters/Basic (1.15.18):
- KSCrash/Recording
- KSCrash/Reporting/Filters/Base
registros:
[0 KSCrash 0x102e22754 ksthread_getQueueName + 132
1 KSCrash 0x102e22738 ksthread_getQueueName + 104
2 KSCrash 0x102e0a4c0 monitorCachedData + 288
3 libsystem_pthread.dylib 0x185bac2b4 _pthread_body + 308
4 libsystem_pthread.dylib 0x185bac180 _pthread_body + 310
5 libsystem_pthread.dylib 0x185baab74 thread_start + 4]
Acabo de ver el mismo bloqueo en KSCrash 1.15.18:
Thread 2 Crashed:
0 KSCrash 0x0000000103052280 ksthread_getQueueName + 320128 (KSThread.c:87)
1 KSCrash 0x0000000103052268 ksthread_getQueueName + 320104 (KSThread.c:80)
2 KSCrash 0x000000010302b050 monitorCachedData + 159824 (KSCrashCachedData.c:139)
3 libsystem_pthread.dylib 0x0000000182d6c31c 0x182d6a000 + 8988 ( + 308)
4 libsystem_pthread.dylib 0x0000000182d6c1e8 0x182d6a000 + 8680 (_pthread_start + 312)
El bloqueo se informa en esta línea, según el OP:
if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
Con los informes de CrashDoctor:
CrashDoctor Diagnosis: Attempted to dereference garbage pointer 0x16da23180.
Las estadísticas de la aplicación indican que la aplicación estaba en segundo plano. ¡No estoy seguro si eso tiene algún impacto en esta investigación!
Dado que idInfo
está desreferenciado en la línea 79 sobre el sitio del bloqueo, supongo que es la desreferenciación de dispatch_queue_ptr
lo que está causando el bloqueo. ¿Esto debe significar que el cheque ksmem_isMemoryReadable
de dispatch_queue_ptr
en la línea 80 no está haciendo su trabajo?
Me temo que todavía no entiendo cómo funcionan ksmem_isMemoryReadable
y sus destinatarios, ¡así que estoy atascado ahora!
Hola, tengo el mismo problema en una de nuestras aplicaciones con Sentry.
KSCaccidente
0x100faa834
ksthread_getQueueNameKSCrash/Source/KSCrash/Recording/Tools/KSThread.c:87
KSCaccidente
0x100f925a0
actualizarThreadListKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:84
KSCaccidente
0x100f925a0
monitorCachedDataKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:137
Podfile.lock:
Mejor
@oleksandrlysenkov , ¿puedes reproducir el accidente?
@Kmohamed Personalmente, no puedo reproducir en mis dispositivos, pero todos los días recibo un registro de Crashlytics sobre este error y actualmente es el bloqueo más frecuente en 2 de mis proyectos.
@oleksandrlysenkov una pregunta secundaria ¿por qué está usando KSCRash y Crashlytics?
Me acaba de pasar el accidente! Ocurrió al poner en primer plano la aplicación. La aplicación se bloqueó inmediatamente después de ponerla en primer plano: la interfaz de usuario apareció brevemente y luego desapareció, como es típico en un bloqueo.
Desafortunadamente, estaba en una compilación de depuración para la que no tengo símbolos, pero el seguimiento de la pila del subproceso 0 y el subproceso que falla muestran lo que estaba haciendo la aplicación:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x00000000 at 0x000000016c2e7180
Crashed Thread: 2
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 QuartzCore 0x00000001882086c8 CA::Layer::mark_context_changed+ 1222344 (CA::Transaction*) + 48
1 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
2 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
3 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
4 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
5 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
6 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
7 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
8 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
9 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
10 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
11 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
12 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
13 QuartzCore 0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
14 QuartzCore 0x0000000188210078 CA::Layer::set_visible+ 1253496 (unsigned int) + 268
15 QuartzCore 0x0000000188170790 CA::Context::set_layer+ 599952 (void const*) + 228
16 UIKit 0x000000018dc57818 +[_UIContextBinder createContextForBindable:withSubstrate:] + 1080
17 UIKit 0x000000018dc57380 -[_UIContextBinder _contextForBindable:] + 132
18 UIKit 0x000000018dc22dc8 -[_UIContextBinder updateBindableOrderWithTest:force:] + 472
19 UIKit 0x000000018dc22a14 -[_UIContextBinder createContextsWithTest:creationAction:] + 100
20 UIKit 0x000000018dc25bb4 -[__UICanvasLifecycleMonitor_Compatability activateEventsOnly:withContext:completion:] + 784
21 UIKit 0x000000018e8bb72c __82-[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:]_block_invoke + 296
22 UIKit 0x000000018dc25268 -[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:] + 432
23 UIKit 0x000000018e6a09b8 __125-[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:]_block_invoke + 220
24 UIKit 0x000000018e7eeae8 _performActionsWithDelayForTransitionContext + 112
25 UIKit 0x000000018dc24c88 -[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:] + 248
26 UIKit 0x000000018dc24624 -[_UICanvas scene:didUpdateWithDiff:transitionContext:completion:] + 368
27 UIKit 0x000000018dc623b0 -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 468
28 FrontBoardServices 0x0000000186888f24 __80-[FBSSceneImpl updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.362 + 212
29 libdispatch.dylib 0x000000018397cae4 _dispatch_client_callout + 16
30 libdispatch.dylib 0x00000001839b8b0c _dispatch_block_invoke_direct$VARIANT$armv81 + 216
31 FrontBoardServices 0x00000001868bc878 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 36
32 FrontBoardServices 0x00000001868bc51c -[FBSSerialQueue _performNext] + 404
33 FrontBoardServices 0x00000001868bcab8 -[FBSSerialQueue _performNextFromRunLoopSource] + 56
34 CoreFoundation 0x0000000184033404 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
35 CoreFoundation 0x0000000184032c2c __CFRunLoopDoSources0 + 276
36 CoreFoundation 0x000000018403079c __CFRunLoopRun + 1204
37 CoreFoundation 0x0000000183f50da8 CFRunLoopRunSpecific + 552
38 GraphicsServices 0x0000000185f33020 GSEventRunModal + 100
39 UIKit 0x000000018df3178c UIApplicationMain + 236
40 Charles 0x00000001048e51b8 0x10471c000 + 1872312 (main + 76)
41 libdyld.dylib 0x00000001839e1fc0 start + 4
Thread 2 Crashed:
0 KSCrash 0x00000001053da84c 0x105358000 + 534604 (ksthread_getQueueName + 280)
1 KSCrash 0x00000001053da828 0x105358000 + 534568 (ksthread_getQueueName + 244)
2 KSCrash 0x0000000105397bb0 0x105358000 + 261040 (updateThreadList + 436)
3 KSCrash 0x0000000105397710 0x105358000 + 259856 (monitorCachedData + 56)
4 libsystem_pthread.dylib 0x0000000183cb1220 _pthread_body + 272
5 libsystem_pthread.dylib 0x0000000183cb1110 _pthread_body + 0
Thread 3 name: KSCrash Exception Handler (Secondary)
Thread 3:
0 libsystem_kernel.dylib 0x0000000183aefe08 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x0000000183aefc80 mach_msg + 72
2 KSCrash 0x00000001053a465c 0x105358000 + 312924 (handleExceptions + 268)
3 libsystem_pthread.dylib 0x0000000183cb1220 _pthread_body + 272
4 libsystem_pthread.dylib 0x0000000183cb1110 _pthread_body + 0
Thread 4 name: KSCrash Exception Handler (Primary)
Thread 4:
@Kmohamed Usamos Crashlytics para el registro general de fallas junto con Fabric y KSCrash dentro de otras herramientas como XCGLogger
Pasamos de Crashlytics a Sentry. Se eliminan todas las fuentes de Crashlatics.
El bloqueo también aparece en XCode=>Organizer=>Crashes :: AppStore=> (una versión lanzada) => KSCrash ... Todo en el subproceso 3, todo en KSCrash ksthread_getQueueName referido a:
//thread_handle shouldn't be 0 also, because
//identifier_info->dispatch_qaddr = identifier_info->thread_handle + get_dispatchqueue_offset_from_proc(thread->task->bsd_info);
if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
{
KSLOG_TRACE("This thread doesn't have a dispatch queue attached : %p", thread);
return false;
}
Este número aparece en nuestro Sentry de 10 a 20 veces al día.
Parece que nuestros bloqueos ocurren después de la terminación de la aplicación por falta de memoria debido a que está involucrado el recolector de elementos no utilizados: "Intento de desreferenciar el puntero de elementos no utilizados 0x16b717180".
Todos los dispositivos tienen poca memoria, por ejemplo: Memoria | Total: 1,9 GB / Gratis: 55,8 MB / Utilizable: 1,7 GB
Toda la memoria libre por debajo de 100 MB, la mayoría por debajo de 50 MB
Y nuestro registro adicional de Sentry con migas de pan muestra los eventos en ese orden:
A veces (40-50 % de todos los informes), el bloqueo aparece en: AppDelegate applicationWillResignActive. Entonces, el usuario debe reiniciar la aplicación dos veces o un usuario debe reiniciar la aplicación 3 veces.
Para las pruebas, pude reproducir la terminación de la aplicación OOM mediante una segunda aplicación en primer plano que solo come memoria como: https://stackoverflow.com/questions/18640414/ios-alloc-objects-until-didreceivememorywarning-is-called/18641099#18641099
Para reducir el tiempo de uso crítico de la memoria, inicialmente solicito la mitad de la memoria del dispositivo como:
-(void)eatMemoryBigChunck
{
NSLog(@"Eating eatMemoryBigChunck");
unsigned long dinnerLength = 1024 * 1024 * 500;
...
Atención, intente esto en el dispositivo, su simulador puede compartir memoria con su Mac host.
@kstenerud Creo que esta es una solución aceptable para este bloqueo hasta que alguien encuentre una mejor # 281
El bloqueo sigue apareciendo, @kstenerud espero que pueda encontrar una solución. Después de una investigación adicional que encontré, ese bloqueo apareció justo después de la actualización de la versión 1.15.16 a la 1.15.18. No soy tan bueno en ObjC, pero lógicamente este cambio provocó que apareciera el bloqueo: http://prntscr.com/jdpc70 http://prntscr.com/jdpcrd
Enlace a detalles sobre el accidente: http://crashes.to/s/149088e734b
@Kmohamed No estoy seguro de cómo su solicitud de extracción puede resolver el problema que aparece en mi aplicación. Su cambio está en la línea 94 de KSCrash.c, pero aparece un bloqueo en la línea 87
Sin embargo, la única forma de evitar el bloqueo, supongo, es usar la versión 1.15.16 de KSCrash.
Tengo un informe de bloqueo de iTunes Connect que contiene más información que podría ser valiosa. Más información de la que he visto antes.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000016d813180
VM Region Info: 0x16d813180 is not in any region. Bytes after previous region: 553345 Bytes before following region: 20096
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
Stack 000000016d690000-000000016d78c000 [ 1008K] rw-/rwx SM=PRV thread 0
---> GAP OF 0x8c000 BYTES
Stack Guard 000000016d818000-000000016d81c000 [ 16K] ---/rwx SM=NUL
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread: 2
Thread 2 Crashed:
0 KSCrash 0x0000000102d42280 ksthread_getQueueName + 128 (KSThread.c:87)
1 KSCrash 0x0000000102d42268 ksthread_getQueueName + 104 (KSThread.c:80)
2 KSCrash 0x0000000102d1b050 monitorCachedData + 288 (KSCrashCachedData.c:84)
3 libsystem_pthread.dylib 0x0000000181825220 _pthread_body + 272 (pthread.c:740)
4 libsystem_pthread.dylib 0x0000000181825110 _pthread_start + 292 (pthread.c:799)
5 libsystem_pthread.dylib 0x0000000181823b10 thread_start + 4
Yo también
¡¡aquí igual!!
Este es también nuestro accidente número uno en este momento.
Este es el principal bloqueo de mi aplicación
Mismo problema aquí. Recibir este bloqueo de vez en cuando a través de Sentry.
Detalles:
OS Version: iOS 11.3.1 (15E302)
Report Version: 104
Crashed Thread: 2
Application Specific Information:
Attempted to dereference garbage pointer 0x16dc8f180.
Thread 2 Crashed:
0 KSCrash 0x10282dba8 ksthread_getQueueName (KSThread.c:87)
1 KSCrash 0x102815a38 [inlined] updateThreadList (KSCrashCachedData.c:84)
2 KSCrash 0x102815a38 monitorCachedData (KSCrashCachedData.c:137)
3 libsystem_pthread.dylib 0x305450220 <redacted>
4 libsystem_pthread.dylib 0x305450110 _pthread_start
@WingedDoom @xlbs-rm Si está actualizando a la última versión de sentry-cocoa
4.x.x
esto debería solucionarse allí, ya que lo solucionamos nosotros mismos en KSCrash.
@HazAT ¡ Oh, gracias por la información! La actualización de Sentry solucionó el problema.
@HazAT , ¿arregló esto simplemente eliminando la funcionalidad getQueueName o encontró la causa raíz de este bloqueo? Si es así, ¿le importaría crear una solicitud de extracción para que esto se solucione para todos?
@harp79 Acabamos de eliminarlo por ahora, ya que no tuvimos tiempo de profundizar en el problema.
Estamos usando Sentry-Cocoa 4.1.0 y todavía vemos este problema.
¿Alguien más se encuentra con esto todavía?
Sí, sigue siendo un problema. Nuestro bloqueador número uno (y seis por alguna razón) según lo informado por Crashlytics
Aquí igual
Tengo entendido que Sentry 4.1.0 ya no usa esto.
Comentario más útil
@HazAT , ¿arregló esto simplemente eliminando la funcionalidad getQueueName o encontró la causa raíz de este bloqueo? Si es así, ¿le importaría crear una solicitud de extracción para que esto se solucione para todos?