dans KSThread.c, EXC_BAD_ACCESS
-->if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
{
KSLOG_TRACE("Ce thread n'a pas de file d'attente attachée : %p", thread);
retourner faux ;
}
Crash : fil de discussion
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
C'est mon crash #1 maintenant, quelqu'un peut-il s'il vous plaît regarder ce problème ? ou dois-je faire ma propre branche de ce projet?
J'ai été trop occupé par le travail ces dernières semaines (nouveau travail). Si quelqu'un fait un PR, je suis généralement rapide pour les fusionner !
D'accord merci!
@ ferrous777 de la chance? je vois aussi ce crash.
Je n'arrive pas à comprendre comment reproduire ce problème, mais il semble que le dispatch_queue_ptr
que nous obtenons de thread_identifier_info_t.dispatch_qaddr
pointe vers un faux emplacement. Je viens de soumettre un PR qui ajoute le KSThread_Test (https://github.com/kstenerud/KSCrash/pull/221) mais je ne pouvais pas comprendre comment ajouter un test qui nous donnerait ce comportement de pointeur factice.
e8977a426ab3ef83939a1929c9c4743ae314bcd1 devrait résoudre ce problème. Il ne vérifiait pas un pointeur valide avant le déréférencement. Ceci est également étiqueté 1.15.5, et je pousse vers les cocopodes.
@kstenerud Salut mec, j'ai vérifié votre commit
mais pour cette ligne de code :
dispatch_queue_t* dispatch_queue_ptr = (dispatch_queue_t*)idInfo->dispatch_qaddr ;
Vous n'avez pas eu d'erreurs lors de la construction ?
J'ai la même erreur/crash, version :
- 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
journaux :
[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]
Je viens de voir le même crash dans 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)
Le crash est signalé sur cette ligne, selon l'OP :
if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
Avec les rapports CrashDoctor :
CrashDoctor Diagnosis: Attempted to dereference garbage pointer 0x16da23180.
Les statistiques de l'application indiquent que l'application était en arrière-plan. Je ne sais pas si cela a un impact sur cette enquête !
Étant donné que idInfo
est déréférencé à la ligne 79 au-dessus du site du crash, je suppose que c'est le déréférencement dispatch_queue_ptr
qui est à l'origine du crash. Cela doit signifier que la vérification ksmem_isMemoryReadable
de dispatch_queue_ptr
à la ligne 80 ne fait pas son travail ?
J'ai bien peur de ne pas encore comprendre le fonctionnement ksmem_isMemoryReadable
et de ses callees, alors je suis bloqué maintenant !
Salut, j'ai le même problème dans l'une de nos applications avec sentinelle
KSCrashGenericName
0x100faa834
ksthread_getQueueNameKSCrash/Source/KSCrash/Recording/Tools/KSThread.c:87
KSCrashGenericName
0x100f925a0
updateThreadListKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:84
KSCrashGenericName
0x100f925a0
monitorCachedDataKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:137
Podfile.lock :
Meilleur
@oleksandrlysenkov es-tu capable de reproduire le crash ?
@Kmohamed Personnellement, je ne suis pas en mesure de reproduire sur mes appareils, mais chaque jour, je reçois une connexion Crashlytics à propos de ce bogue et actuellement, c'est un plantage le plus apparaissant sur 2 de mes projets.
@oleksandrlysenkov une question secondaire pourquoi vous utilisez KSCrash et Crashlytics ?
Je viens d'avoir l'accident qui m'arrive ! Cela s'est produit lors de la mise en avant de l'application. L'application s'est écrasée immédiatement après le premier plan - l'interface utilisateur est apparue brièvement puis a disparu, comme c'est généralement le cas pour un plantage.
Malheureusement, c'était sur une version de débogage pour laquelle je n'ai pas de symboles, mais la trace de la pile du thread 0 et le thread qui plante montrent ce que faisait l'application :
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 Nous utilisons Crashlytics pour la journalisation générale des accidents avec Fabric et KSCrash à l'intérieur d'autres outils comme XCGLogger
Nous sommes passés de Crashlytics à Sentry. Toutes les sources Crashlatics sont supprimées.
Le crash apparaît également dans XCode=>Organizer=>Crashes :: AppStore=> (a Released Version) => KSCrash ... All on Thread 3, all in KSCrash ksthread_getQueueName fait référence à :
//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;
}
Ce numéro apparaît dans notre Sentry 10 à 20 fois par jour.
Il semble que nos plantages se produisent après l'arrêt de l'application en mémoire insuffisante en raison de l'implication du Garbadge Collector : "Tentative de déréférencement du pointeur d'ordures 0x16b717180."
Tous les appareils ont peu de mémoire, par exemple : Mémoire | Total : 1,9 Go / Libre : 55,8 Mo / Utilisable : 1,7 Go
Toutes les mémoires libres inférieures à 100 Mo, la plupart d'entre elles inférieures à 50 Mo
Et notre journalisation supplémentaire Sentry avec Breadcrumbs affiche les événements dans cet ordre :
Parfois (40 à 50 % de tous les rapports), le crash apparaît sur : AppDelegate applicationWillResignActive. Ensuite, l'utilisateur doit redémarrer l'application deux fois ou un utilisateur doit redémarrer l'application 3 fois.
Pour les tests, je pourrais reproduire la résiliation de l'application OOM par une deuxième application de premier plan qui ne fait que manger de la mémoire comme : https://stackoverflow.com/questions/18640414/ios-alloc-objects-until-didreceivememorywarning-is-called/18641099#18641099
Pour réduire le temps d'utilisation critique de la mémoire, je demande initialement la moitié de la mémoire de l'appareil comme :
-(void)eatMemoryBigChunck
{
NSLog(@"Eating eatMemoryBigChunck");
unsigned long dinnerLength = 1024 * 1024 * 500;
...
Attention essayez ceci sur Device, votre simulateur peut partager de la mémoire avec votre Mac hôte.
@kstenerud Je pense que c'est une solution acceptable pour ce crash jusqu'à ce que quelqu'un en trouve une meilleure # 281
Le crash apparaît toujours, @kstenerud espère que vous pourrez trouver une solution. Après une enquête supplémentaire que j'ai trouvée, ce crash est apparu juste après la mise à jour de la version 1.15.16 à 1.15.18. Je ne suis pas très bon en ObjC, mais logiquement, ce changement a provoqué l'apparition du crash - http://prntscr.com/jdpc70 http://prntscr.com/jdpcrd
Lien vers les détails du crash : http://crashes.to/s/149088e734b
@Kmohamed Je ne sais pas comment votre demande Pull peut résoudre le problème qui apparaît dans mon application. Votre modification est à la ligne 94 de KSCrash.c, mais le plantage apparaît à la ligne 87
Pourtant, la seule façon d'éviter le crash, je suppose, est d'utiliser la version 1.15.16 de KSCrash.
J'ai reçu un rapport d'incident d'iTunes Connect qui contient des informations supplémentaires qui pourraient être utiles. Plus d'informations que ce que j'ai vu auparavant.
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
Moi aussi
pareil ici!!
C'est aussi notre crash numéro un en ce moment.
C'est le top 1 des crashs de mon application
Même problème ici. Recevoir ce crash de temps en temps via Sentry.
Des détails:
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 vous mettez à jour vers la dernière version de sentry-cocoa
4.x.x
, cela devrait être corrigé ici puisque nous l'avons corrigé nous-mêmes dans KSCrash.
@HazAT oh, merci pour l'information ! La mise à jour de la sentinelle a effectivement résolu le problème.
@HazAT avez-vous résolu ce problème en supprimant simplement la fonctionnalité getQueueName ou avez-vous trouvé la cause première de ce plantage ? Si oui, cela vous dérangerait-il de créer une demande d'extraction afin que cela soit corrigé pour tout le monde ?
@ harp79 Nous venons de le supprimer pour le moment car nous n'avons pas eu le temps de creuser complètement le problème.
Nous utilisons Sentry-Cocoa 4.1.0 et nous rencontrons toujours ce problème.
Quelqu'un d'autre traverse-t-il encore cela?
Oui, toujours un problème. Notre crash numéro un (et six pour une raison quelconque) tel que rapporté par Crashlytics
Pareil ici
Ma compréhension est que Sentry 4.1.0 ne l'utilise plus.
Commentaire le plus utile
@HazAT avez-vous résolu ce problème en supprimant simplement la fonctionnalité getQueueName ou avez-vous trouvé la cause première de ce plantage ? Si oui, cela vous dérangerait-il de créer une demande d'extraction afin que cela soit corrigé pour tout le monde ?