Crash se produisant lorsque l'application passe en arrière-plan

Question

Je ne sais pas comment reproduire ce crash mais cela se passe beaucoup. La pile montre que l'application passe en arrière-plan au # 16 ci-dessous.

Je n'ai trouvé aucune aide concernant ce crash. Lorsque l'application passe en arrière-plan, pourquoi essaie-t-elle de traiter les tâches du clavier? Les lignes # 1-5 montrent qu'il essaie de faire des tâches au clavier.

Que pourrait-il se passer ici?

# 1 _dispatch_barrier_sync_f_slow + 518 (libdispatch.dylib + 0x00010c68)  0x0 
# 2 __88-[UIKeyboardLayout recognizer:releaseTouchToLayoutWithId:startPoint:endPoint:whenReady:]_block_invoke + 95 (UIKit + 0x004297fd)  0x0 
# 3 __88-[UIKeyboardLayout recognizer:releaseTouchToLayoutWithId:startPoint:endPoint:whenReady:]_block_invoke + 93 (UIKit + 0x004297fb) 0x74cd0c8 
# 4 -[UIKeyboardTaskQueue continueExecutionOnMainThread] + 393 (UIKit + 0x0003737d) 0x74cd0f8 
# 5 __39-[UIKeyboardLayout resetHRRLayoutState]_block_invoke + 625 (UIKit + 0x0042a809) 0x74cd118 
# 6 _dispatch_client_callout + 21 (libdispatch.dylib + 0x00001781) 0x74cd2b0 
# 7 _dispatch_barrier_sync_f_invoke + 49 (libdispatch.dylib + 0x0000da33) 0x74cd2c0 
# 8 -[UIKeyboardLayout resetHRRLayoutState] + 107 (UIKit + 0x0042a56b) 0x74cd2dc 
# 9 +[UIKeyboardImpl applicationWillResignActive:] + 223 (UIKit + 0x0012fe35) 0x74cd304 
# 10 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 9 (CoreFoundation + 0x000a6db7) 0x74cd318 
# 11 _CFXRegistrationPost + 381 (CoreFoundation + 0x000a66f7) 0x74cd320 
# 12 ___CFXNotificationPost_block_invoke + 39 (CoreFoundation + 0x000a64df) 0x74cd35c 
# 13 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1241 (CoreFoundation + 0x00101307) 0x74cd378 
# 14 _CFXNotificationPost + 539 (CoreFoundation + 0x0000a033) 0x74cd6f0 
# 15 -[NSNotificationCenter postNotificationName:object:userInfo:] + 65 (Foundation + 0x000060ab) 0x74cd8bc 
# 16 -[UIApplication _deactivateForReason:notify:] + 815 (UIKit + 0x00073e0f) 0x74cd8d0 
# 17 __61-[UIApplication _sceneSettingsPreLifecycleEventDiffInspector]_block_invoke + 93 (UIKit + 0x00282255) 0x74cd908 
# 18 __52-[FBSSettingsDiffInspector inspectDiff:withContext:]_block_invoke.27 + 165 (FrontBoardServices + 0x00020cfd) 0x74cd928 
# 19 __NSIndexSetEnumerate + 437 (Foundation + 0x000af3df) 0x74cd9b8 
# 20 -[NSIndexSet enumerateIndexesWithOptions:usingBlock:] + 65 (Foundation + 0x00030bcd) 0x74cda48 
# 21 -[BSSettingsDiff inspectChangesWithBlock:] + 101 (BaseBoard + 0x00035a57) 0x74cda6c 
# 22 -[FBSSettingsDiff inspectOtherChangesWithBlock:] + 89 (FrontBoardServices + 0x0001b025) 0x74cda98 
# 23 -[FBSSettingsDiffInspector inspectDiff:withContext:] + 299 (FrontBoardServices + 0x00020b5b) 0x74cdab8 
# 24 __70-[UIApplication scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke + 101 (UIKit + 0x00283427) 0x74cdb20 
# 25 -[UIApplication scene:didUpdateWithDiff:transitionContext:completion:] + 823 (UIKit + 0x00283131) 0x74cdb50 
# 26 -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 411 (UIKit + 0x00588aa1) 0x74cdc18 
# 27 __80-[FBSSceneImpl updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke + 209 (FrontBoardServices + 0x0000af65) 0x74cdc7c 
# 28 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 17 (FrontBoardServices + 0x00035c11) 0x74cdca8 
# 29 -[FBSSerialQueue _performNext] + 219 (FrontBoardServices + 0x00035acb) 0x74cdcb8 
# 30 -[FBSSerialQueue _performNextFromRunLoopSource] + 43 (FrontBoardServices + 0x00035db5) 0x74cdd94 
# 31 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 11 (CoreFoundation + 0x000b6fdb) 0x74cdda4 
# 32 __CFRunLoopDoSources0 + 423 (CoreFoundation + 0x000b6b03) 0x74cddac 
# 33 __CFRunLoopRun + 1159 (CoreFoundation + 0x000b4f4f) 0x74cdde8 
# 34 CFRunLoopRunSpecific + 469 (CoreFoundation + 0x000080ed) 0x74cea88 
# 35 CFRunLoopRunInMode + 103 (CoreFoundation + 0x00007f0f) 0x74ceb70 
# 36 GSEventRunModal + 79 (GraphicsServices + 0x00009b3f) 0x74ceb98 
# 37 UIApplicationMain + 149 (UIKit + 0x00071e81) 0x74cebb8 
# 38 UIApplicationMain (ApplicationHooks.m:50) (MyApp + 0x0002235f) 0x74cebdc 
# 39 main (main.mm:18) (MyApp + 0x003a227f) 0x74cebfc 
# 40 0x1b33a4e9 in start + 1 (libdyld.dylib + 0x000034e9) 0x74cec18 

Discussion 1:

# 1 0x1b40d808 in __psynch_cvwait + 24 (libsystem_kernel.dylib + 0x00015808)  0x0 
# 2 0x1b4c3cb3 in _pthread_cond_wait + 561 (libsystem_pthread.dylib + 0x00002cb3)  0x0 
# 3 0x1b4c5033 in pthread_cond_wait + 37 (libsystem_pthread.dylib + 0x00004033) 0x190e50a0 
# 4 0x1be0ed7 in SyncCondition::Wait() (SyncSynchronization.h:592) (MyApp + 0x01ba9ed7) 0x190e50ac 
# 5 0x1be0f0b in SyncCondition::WaitForDuration(unsigned long) (MyAppSync.cpp:469) (MyApp + 0x01ba9f0b) 0x190e50b4 
# 6 0x446ebef in invocation function for block in wlm_dispatch_create_block_wrapper(void() block_pointer) (MyAppThread_objc.mm:203) (MyApp + 0x04437bef) 0x190e5e78 
# 7 0x1b30d795 in _dispatch_call_block_and_release + 9 (libdispatch.dylib + 0x00001795) 0x190e5f24 
# 8 0x1b31ab1b in _dispatch_queue_override_invoke + 535 (libdispatch.dylib + 0x0000eb1b) 0x190e5f30 
# 9 0x1b31c1b3 in _dispatch_root_queue_drain + 325 (libdispatch.dylib + 0x000101b3) 0x190e5f58 
# 10 0x1b31c00d in _dispatch_worker_thread3 + 105 (libdispatch.dylib + 0x0001000d) 0x190e5f90 
# 11 0x1b4c28eb in _pthread_wqthread + 1039 (libsystem_pthread.dylib + 0x000018eb) 0x190e5fa0 
# 12 0x1b4c24ca in start_wqthread + 6 (libsystem_pthread.dylib + 0x000014ca) 0x190e5fe0 

Answer 1

Sans savoir quoi que ce soit au sujet de votre application: s'il utilise OpenGL, strictement UIKit, etc. Et sans connaître le type d'exception que vous voyez ou le cas d'utilisation qui provoque cela, voici quelques choses à considérer. Si une application se bloque en arrière-plan, en particulier lorsque vous ne voyez pas ces plantages lors du débogage dans Xcode (ce sont des plantages de l'utilisateur?), Il faut regarder ce qui se passe lorsque votre application passe en arrière-plan , ce qui signifie applicationWillResignActive et applicationDidEnterBackground, mais aussi toutes les tâches planifiées (minuteurs, code asynchrone pouvant être en vol, boucles de mise à jour planifiées, etc.). Arrêtez/mettez en pause toutes les tâches longues ou faites-les dans une tâche en arrière-plan en utilisant beginBackgroundTaskWithName/endBackgroundTask Et enfin, assurez-vous que votre code ne tarde pas à retourner depuis applicationDidEnterBackground ou que le système va tuer votre application

D'autres choses à réaliser sont que l'arrière-plan/la démission ne se fait pas simplement en appuyant sur le bouton d'accueil. Votre application est suspendue lorsque vous ouvrez le centre de notifications, accédez à la boîte de dialogue d'authentification d'alerte Touch ID, recevez un appel, etc. Peut-être que cela vous aidera à déterminer le scénario qui le provoque. La suppression de clavier est intéressante et je pense que cela indique qu'une vue reçoit un message endEditing ou quelque chose comme ça lorsque la vue devient inactive. Avez-vous du code qui s'exécute lorsque le clavier se ferme? Si c'est le cas, assurez-vous de ne rien faire que vous ne devriez pas faire en arrière-plan. Le fait qu'il s'agisse d'une panne d'interface utilisateur m'a fait penser à quelque chose qui n'est pas directement lié à l'arrière-plan, et qui fait des appels d'interface utilisateur sur un thread autre que le thread principal, ce qui n'est pas sûr. Xcode 9 a un vérificateur pour cela, donc vous pouvez l'activer et voir s'il trouve quelque chose. Ceux-ci ont tendance à être difficiles à traquer et Xc9 aide beaucoup avec ça. Les journaux de plantage que vous devriez voir dans Xcode (d'Apple) s'il s'agit d'une application publiée, ou sur les appareils des personnes qui plantent, auront beaucoup plus d'informations que les deux threads ci-dessus. Juste ces deux threads ne sont pas super utile pour suivre cela. Si vous pouvez obtenir un journal de crash iOS complet et symbolisé, cela sera probablement plus facile à comprendre. Si vous pouvez provoquer le plantage, mais pas pendant le débogage dans Xcode, vous pouvez également exécuter l'application en dehors de Xcode, mais ouvrez la fenêtre Fenêtre> Périphériques et simulateurs et observez la console système du périphérique lorsque le plantage se produit. Peut-être y aura-t-il un indice, comme Springboard tuant votre application. Vous pouvez également regarder les journaux après le fait (pas en direct) de la même manière. Vous devrez isoler l'heure du crash pour savoir où chercher dans le journal système, mais les journaux de plantage de l'application sur le téléphone devraient vous aider.