Mon application est bloquée uniquement sur iOS13 avec la pile d'appels suivante:
#57. Crashed: com.twitter.crashlytics.ios.exception
0 myapp 0x105d6d494 CLSProcessRecordAllThreads + 376 (CLSProcess.c:376)
1 myapp 0x105d6d87c CLSProcessRecordAllThreads + 407 (CLSProcess.c:407)
2 myapp 0x105d5d58c CLSHandler + 26 (CLSHandler.m:26)
3 myapp 0x105d6bab4 __CLSExceptionRecord_block_invoke + 198 (CLSException.mm:198)
4 libdispatch.dylib 0x1be5c100c _dispatch_client_callout + 20
5 libdispatch.dylib 0x1be5cd804 _dispatch_lane_barrier_sync_invoke_and_complete + 60
6 myapp 0x105d6b55c CLSExceptionRecord + 205 (CLSException.mm:205)
7 myapp 0x105d6b390 CLSExceptionRecordNSException + 102 (CLSException.mm:102)
8 myapp 0x105d6afb4 CLSTerminateHandler() + 258 (CLSException.mm:258)
9 libc++abi.dylib 0x1be6d9634 std::__terminate(void (*)()) + 20
10 libc++abi.dylib 0x1be6d8f58 __cxa_get_exception_ptr + 34
11 libc++abi.dylib 0x1be6d8f10 __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) + 126
12 libobjc.A.dylib 0x1be6341f8 _objc_exception_destructor(void*) + 362
13 Foundation 0x1bee05434 -[NSISEngine tryToOptimizeReturningMutuallyExclusiveConstraints] + 322
14 Foundation 0x1bebfeb94 -[NSISEngine _optimizeWithoutRebuilding] + 72
15 Foundation 0x1bebfeaa8 -[NSISEngine optimize] + 116
16 Foundation 0x1bebfe718 -[NSISEngine performPendingChangeNotifications] + 116
17 UIKitCore 0x1c2e447c4 -[UIView(Hierarchy) layoutSubviews] + 316
18 UIKitCore 0x1c23c6948 -[UIButton layoutSubviews] + 596
19 UIKitCore 0x1c2e57abc -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2156
20 libobjc.A.dylib 0x1be62faf0 -[NSObject performSelector:withObject:] + 68
21 QuartzCore 0x1c53f60f4 -[CALayer layoutSublayers] + 292
22 QuartzCore 0x1c53f63fc CA::Layer::layout_if_needed(CA::Transaction*) + 484
23 QuartzCore 0x1c5409964 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 140
24 QuartzCore 0x1c534ec1c CA::Context::commit_transaction(CA::Transaction*, double) + 308
25 QuartzCore 0x1c5379bd8 CA::Transaction::commit() + 684
26 QuartzCore 0x1c537abc0 CA::Transaction::release_thread(void*) + 232
27 libsystem_pthread.dylib 0x1be62c3c0 _pthread_tsd_cleanup + 584
28 libsystem_pthread.dylib 0x1be624dbc _pthread_exit + 84
29 libsystem_pthread.dylib 0x1be626de8 _pthread_wqthread_legacy_worker_wrap + 98
30 libsystem_pthread.dylib 0x1be626b30 _pthread_wqthread + 424
31 libsystem_pthread.dylib 0x1be62cc78 start_wqthread + 8
--
Fatal Exception: NSInternalInconsistencyException
Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.
0 CoreFoundation 0x1be919c30 __exceptionPreprocess
1 libobjc.A.dylib 0x1be6340c8 objc_exception_throw
2 Foundation 0x1bee05434 -[NSISEngine tryToOptimizeReturningMutuallyExclusiveConstraints]
3 Foundation 0x1bebfeb94 -[NSISEngine _optimizeWithoutRebuilding]
4 Foundation 0x1bebfeaa8 -[NSISEngine optimize]
5 Foundation 0x1bebfe718 -[NSISEngine performPendingChangeNotifications]
6 UIKitCore 0x1c2e447c4 -[UIView(Hierarchy) layoutSubviews]
7 UIKitCore 0x1c23c6948 -[UIButton layoutSubviews]
8 UIKitCore 0x1c2e57abc -[UIView(CALayerDelegate) layoutSublayersOfLayer:]
9 libobjc.A.dylib 0x1be62faf0 -[NSObject performSelector:withObject:]
10 QuartzCore 0x1c53f60f4 -[CALayer layoutSublayers]
11 QuartzCore 0x1c53f63fc CA::Layer::layout_if_needed(CA::Transaction*)
12 QuartzCore 0x1c5409964 CA::Layer::layout_and_display_if_needed(CA::Transaction*)
13 QuartzCore 0x1c534ec1c CA::Context::commit_transaction(CA::Transaction*, double)
14 QuartzCore 0x1c5379bd8 CA::Transaction::commit()
15 QuartzCore 0x1c537abc0 CA::Transaction::release_thread(void*)
16 libsystem_pthread.dylib 0x1be62c3c0 _pthread_tsd_cleanup
17 libsystem_pthread.dylib 0x1be624dbc _pthread_exit
18 libsystem_pthread.dylib 0x1be626de8 _pthread_wqthread_legacy_worker_wrap
19 libsystem_pthread.dylib 0x1be626b30 _pthread_wqthread
20 libsystem_pthread.dylib 0x1be62cc78 start_wqthread
Je n'ai absolument aucune idée de ce qui peut survenir ce problème et comment puis-je reproduire. Il se bloque aléatoirement. J'utilise Crashlytics v3.14 dans mon projet. Quelqu'un est-il confronté au même problème?
crashlytics
ios13
xcode11
bemul12
la source
la source
Réponses:
Tout d'abord, je recommanderais d'activer le "Vérificateur de thread principal", dans Xcode, allez dans Produit -> Schéma -> Modifier le schéma -> Diagnostics, vous devriez voir cette fenêtre
Une autre chose que vous pourriez essayer est d'aller à votre section de point d'arrêt dans Xcode et en cliquant sur le signe + et en ajoutant un point d'arrêt symbolique, qui écoutera un appel spécifique et vous pouvez lui ajouter une condition pour vérifier s'il est appelé sur le thread principal.
S'il vous arrive de trouver votre bogue dans le code, veuillez le poster ici, car je rencontre le même plantage que vous dans mon application, c'est donc aussi loin que je suis allé à trouver le bogue. J'espère que cela vous aide!
la source
Avez-vous activé les annonces Google dans votre application? Il pourrait alors s'agir d'un bogue dans le sdk des annonces Google ou d'un bogue dans l'implémentation du SDK WebKit sur iOS 13. (je ne peux pas commenter, donc je poste ceci comme réponse)
Piggybacking off of this - En parcourant le fil lié ci-dessus, la solution "officielle" de l'équipe Google Ads à partir du 19 novembre 2019 consiste à modifier le plist de votre application pour inclure la clé / paire suivante pour utiliser wkwebview au lieu de uiwebview.
Source: https://groups.google.com/forum/#!category-topic/google-admob-ads-sdk/ios/I4EEWrPPbSc
la source
Ce problème peut être dû au SDK Google Ads (7.5XX + iOS13), a trouvé ce fil .
Les développeurs ont essayé d'utiliser la valeur de paire de clés ci-dessous dans le
Info.plistfichier, comme suggéré par l'équipe Google Ads.Cette diminution du plantage, mais cela donne un autre problème de gel (100% d'utilisation du processeur).
Récemment, Google a publié 7.55.0 avec une note:
essayez donc de mettre à jour le SDK Google Ads vers
7.55.0la source
Afin d'afficher les traces de pile pour vos threads, Crashlytics doit exécuter du code post-crash. Étant donné que ce code s'exécute sur l'un des threads de votre application, Crashlytics capture toujours des informations sur sa propre exécution dans le cadre de ce processus. Vous verrez toujours un thread exécutant la fonction «CLSProcessRecordAllThreads». En fait, vous le verrez plus d'une fois, en raison d'une optimisation du compilateur appelée inline.
Les exceptions ajoutent un peu plus de complexité. Lorsqu'une exception Objective-C ou C ++ n'est pas détectée, Crashlytics enregistre certaines informations à son sujet avant que l'application ne soit autorisée à se terminer. Lorsque cela se produit, la fonction CLSProcessRecordAllThreads doit être exécutée sur le thread qui a levé l'exception. Cela signifie que dans le cas d'une exception, le thread «en panne» aura toujours l'air d'exécuter du code Crashlytics. Ceci est normal et n'est qu'un artefact de la façon dont nous capturons et présentons les traces de pile au moment de l'exception.
la source