Il thread di Crashlytics si è arrestato in modo anomalo solo su iOS13 creato con Xcode11


18

La mia app si arresta in modo anomalo solo su iOS13 con il seguente stack di chiamate:

#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

Non ho assolutamente idea di cosa possa verificarsi questo problema e come posso riprodurlo. Si schianta a caso. Uso Crashlytics v3.14 nel mio progetto. Qualcuno deve affrontare lo stesso problema?


1
Hai ancora questo problema
Anjula S.

Risposte:


9

Prima di tutto consiglierei di attivare il "Controllo thread principale", in Xcode, vai su Prodotto -> Schema -> Modifica schema -> Diagnostica, dovresti vedere questa finestra Scheda diagnostica Un'altra cosa che potresti provare è andare alla sezione del punto di interruzione in Xcode e facendo clic sul segno + e aggiungendo un punto di interruzione simbolico, che ascolterà su una chiamata specifica ed è possibile aggiungere una condizione ad esso per verificare se viene chiamato sul thread principale.

Un punto di interruzione simbolico

Se ti capita di trovare il tuo bug nel codice, pubblicalo qui, poiché sto riscontrando lo stesso crash di te nella mia app, quindi questo è quanto ho scoperto per scoprire il bug. Spero che ti aiuti!


Ho provato questo suggerimento, ma sfortunatamente non ho riscontrato l'incidente.
bemul12,

Il mio problema era nell'autorizzazione locale (touch ID, face ID), presentavo un altro controller di visualizzazione su un thread in background e la mia app si è arrestata in modo anomalo solo in seguito dopo averla utilizzata per circa 2 minuti in modo casuale. Potresti provare a verificarlo
Laurynas Letkauskas,

Se ho capito bene, il tuo problema è stato rilevato dal controllo thread principale e l'hai trovato nella sezione degli avvisi di runtime. Ho controllato molti flussi nella mia app e non ho ricevuto avvisi di runtime dal controllo thread principale.
bemul12,

Non era esattamente nella chiusura dell'autenticazione. In realtà stavo chiamando un metodo delegato dalla chiusura, dicendo a un controller di visualizzazione che l'utente è autenticato, ho iniziato a costruire la schermata principale, che sembrava creare un'istanza di una barra delle schede mentre era ancora sul thread in background, ed è qui che il controllo thread principale ha funzionato, quindi ho scavato e ho scoperto che il problema è che il delegato non viene chiamato nella discussione principale
Laurynas Letkauskas,

17

Hai annunci google abilitati nella tua app? Potrebbe quindi essere un bug in Google Ads SDK o essere un bug nell'implementazione dell'SDK di WebKit su iOS 13. (sry non posso commentare, quindi inserisco questo come risposta)

Escludendo da questo - Leggendo il thread sopra collegato, la soluzione "ufficiale" del team di Google Ads a partire dal 19 novembre 2019 è quella di modificare il piano della tua app per includere la seguente chiave / coppia per utilizzare wkwebview invece di uiwebview.

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

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


Grazie la tua risposta Non ho annunci Google nella mia app, ma ho un UIWebView al suo interno, ma UIWebView fa parte di UIKit, non WebKit.
bemul12,

Usi UIWebView o WKWebview?
own2pwn

2
Lo stesso problema qui. Sto ancora aspettando un nuovo aggiornamento da parte di Google. Nella versione corrente (7.52.0) questo errore esiste ancora.
fdlr,

1
@nab Forse, sì. Uno sviluppatore ha registrato una perdita di entrate, citando che "mostra tasso" è sceso ~ 10% groups.google.com/d/msg/google-admob-ads-sdk/PuHOKMX1mVI/… E un altro calo riportato nella percentuale di "mostra tasso": gruppi .google.com / d / msg / google-admob-ads-sdk / PuHOKMX1mVI /…
262Hz

1
Ecco la soluzione "ufficiale" di Google: groups.google.com/forum/#!category-topic/google-admob-ads-sdk/… ma nota che esiste un problema noto: gli annunci con audio riprodurranno SEMPRE il suono, indipendentemente da dell'interruttore vibrazione acceso.
262Hz

6

Questo problema potrebbe essere dovuto a Google Ads SDK (7.5XX + iOS13), trovato questo thread .

Gli sviluppatori hanno tentato di utilizzare un valore inferiore alla coppia di chiavi nel Info.plistfile come suggerito dal team di Google Ads.

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

Questo arresto è diminuito ma questo sta dando un altro problema di blocco (utilizzo della CPU al 100%).

Recentemente Google ha rilasciato 7.55.0 con una nota:

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

quindi prova ad aggiornare l'SDK per gli annunci Google su 7.55.0


3

Per mostrare le tracce dello stack per i tuoi thread, Crashlytics deve eseguire un po 'di codice post-crash. Poiché questo codice viene eseguito su uno dei thread dell'app, Crashlytics acquisisce sempre informazioni sulla propria esecuzione come parte di questo processo. Vedrai sempre un thread che esegue la funzione "CLSProcessRecordAllThreads". In effetti, lo vedrai più di una volta, a causa di un'ottimizzazione del compilatore chiamata inline. inserisci qui la descrizione dell'immagine Le eccezioni aggiungono un pizzico di complessità in più. Quando un'eccezione Objective-C o C ++ non viene rilevata, Crashlytics registra alcune informazioni al riguardo prima che sia possibile terminare l'app. In questo caso, la funzione CLSProcessRecordAllThreads deve essere eseguita sul thread che ha generato l'eccezione. Ciò significa che, nel caso di un'eccezione, il thread "crashing" sembrerà sempre che stia eseguendo il codice Crashlytics. Questo è normale ed è solo un artefatto di come catturiamo e presentiamo le tracce dello stack al momento dell'eccezione.


1
Dato che "il thread in crash sembrerà sempre che stia eseguendo il codice Crashlytics", come si determina quale sia il thread in crash reale?
Wil0,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.