Le thread Crashlytics s'est écrasé uniquement sur iOS13 construit avec Xcode11


18

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?


1
Avez-vous toujours ce problème
Anjula S.

Réponses:


9

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 Onglet Diagnostics 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.

Un point d'arrêt symbolique

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!


J'ai essayé cette suggestion, mais malheureusement je n'ai pas attrapé le crash.
bemul12

Mon problème était lié à l'autorisation locale (Touch ID, Face ID), je présentais un autre contrôleur de vue sur un thread d'arrière-plan et mon application ne s'est bloquée que plus tard après avoir utilisé l'application pendant environ 2 minutes au hasard. Vous pouvez essayer de vérifier cela
Laurynas Letkauskas

Si je comprends bien, votre problème a été détecté par le vérificateur de thread principal et vous l'avez trouvé dans la section des avertissements d'exécution. J'ai vérifié beaucoup de flux dans mon application et je n'ai pas reçu d'avertissement d'exécution par le vérificateur de thread principal.
bemul12

Ce n'était pas exactement dans la clôture de l'authentification. J'appelais en fait une méthode déléguée depuis la fermeture, disant à un contrôleur de vue que l'utilisateur était authentifié, commençait à créer l'écran principal, qui semblait instancier une barre d'onglets tout en restant sur le thread d'arrière-plan, et c'est là que le vérificateur de thread principal travaillé, donc j'ai creusé et découvert que le délégué appelé pas sur le thread principal est le problème
Laurynas Letkauskas

17

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.

<key>gad_preferred_webview</key>
<string>wkwebview</string>

Source: https://groups.google.com/forum/#!category-topic/google-admob-ads-sdk/ios/I4EEWrPPbSc


Merci votre réponse. Je n'ai pas d'annonces Google dans mon application, mais j'ai une UIWebView à l'intérieur, mais UIWebView fait partie d'UIKit, pas de WebKit.
bemul12

Utilisez-vous UIWebView ou WKWebview?
own2pwn

2
Même problème ici. J'attends toujours une nouvelle mise à jour de Google. Dans la version actuelle (7.52.0), cette erreur existe toujours.
fdlr

1
@nab Peut-être, oui. Un développeur a signalé une perte de revenus, citant que le "taux d' affichage " a chuté de ~ 10% groups.google.com/d/msg/google-admob-ads-sdk/PuHOKMX1mVI/… Et une autre baisse signalée du pourcentage de "taux d' affichage ": groupes .google.com / d / msg / google-admob-ads-sdk / PuHOKMX1mVI /…
262Hz

1
Voici la solution "officielle" de Google: groups.google.com/forum/#!category-topic/google-admob-ads-sdk/… mais notez qu'il y a un problème connu: les annonces avec du son joueront TOUJOURS le son, indépendamment du commutateur de vibration étant activé.
262Hz

6

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.

<key>gad_preferred_webview</key>
<string>wkwebview</string>

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:

Removed all references to UIWebView. UIWebView is no longer supported.

essayez donc de mettre à jour le SDK Google Ads vers 7.55.0


3

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. entrez la description de l'image ici 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.


1
Etant donné que le "thread qui plante va toujours avoir l'air d'exécuter du code Crashlytics", comment déterminez-vous quel est le thread qui plante?
wilc0
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.