2014-09-15 19 views
46

Qualcuno sa che cosa questo tipo di eccezione è su iOS 8?Arresto app con EXC_RESOURCE, eccezione WAKEUPS su iOS 8 GM

=== dalla relazione crash ===

Exception Type: EXC_RESOURCE 
Exception Subtype: WAKEUPS 
Exception Message: (Limit 150/sec) Observed 206/sec over 300 secs 
Triggered by Thread: 14 

sembra accadere solo su iOS 8 ... La nostra applicazione è spento del tutto casualmente a intervalli arbitrari con questa eccezione ..

Qualsiasi gli indizi sono benvenuti Grazie!

+0

Qualche fortuna con questo? Sto ottenendo lo stesso errore con il colpevole: 'Nome thread 4: WebThread' – ohhh

+0

Ho esattamente lo stesso errore. Utilizzo di Xamarin e OpenTok –

+0

Stiamo riscontrando un problema simile con la nostra app che potrebbe essere correlato a ciò che Ryan ha detto di seguito. Fondamentalmente stiamo riproducendo gli effetti sonori usando SKAction playSoundFileNamed: ma a volte, a caso, non suona alcun suono a meno che non esca dall'app e la riprenda più tardi, poi riproduca tutto in una volta, il che suggerisce che qualcosa stia bloccando quelle azioni ... se continui a giocare in questo stato per un po 'alla fine vedrai questo crash ... – gzafra

risposta

18

L'app invia un comando di attivazione a un determinato thread nell'app piuttosto spesso - apparentemente in media 206 volte al secondo. I thread in background in iOS 8 hanno un limite rigido al numero di volte in cui è possibile eseguire un ciclo sleep/wake su ogni thread al secondo, e avere un conteggio elevato di solito indica che qualcosa non funziona/è inefficiente nella gestione dei thread.

Senza visualizzare il codice, la mia raccomandazione è di controllare gli algoritmi C++ per le chiamate di sospensione/sveglia o di eseguire il multithread del processo in background per avviare nuovi thread in ogni ciclo.

Ray Wenderlich ha un fantastico tutorial sul sistema di Apple per il multithreading, Grand Central Dispactch, che potrebbe anche essere una buona risorsa per voi: http://www.raywenderlich.com/60749/grand-central-dispatch-in-depth-part-1

+0

Esiste un modo per controllare e limitare il numero di chiamate di attivazione su un determinato thread? Perché, a quanto pare, il thread in esecuzione si fermerà dopo che il lavoro è terminato, non c'è motivo di provare a svegliarlo così spesso! –

+0

Puoi fornire un esempio di codice per aiutarmi a capire meglio questo problema? –

+0

L'uso di @synchronized nei thread in background può causare questo problema? –

2

Utilizzando Xamarin, abbiamo ottenuto questo punto. Stavamo usando 4 SemaphoreSlim che stavano aspettando allo stesso tempo per un periodo di tempo troppo lungo. La sostituzione di SemaphoreSlim con un'altra sincronizzazione primitiva (AutoResetEvent nel nostro caso per simulare un semaforo di 1 elemento) ha risolto il problema.

0

Nel mio caso su iOS 9.1 questo è scattato dal filo 2 che sembra essere un po 'di lavoro per la causa pilota GLES la ricerca attraverso le fonti del progetto non vedo alcun riferimento a GPUTools.

Thread 2 name: gputools.smt_poll.0x145722df0 
Thread 2 Attributed: 
0 libsystem_kernel.dylib   0x000000019a8b7440 __semwait_signal + 8 
1 libsystem_c.dylib    0x000000019a7c9e2c nanosleep + 212 
2 libsystem_c.dylib    0x000000019a7c9d4c 0x19a7bc000 + 56652 
3 GPUToolsCore     0x0000000100ba0ae0 0x100b98000 + 35552 
4 libsystem_pthread.dylib   0x000000019a97fb28 _pthread_body + 156 
5 libsystem_pthread.dylib   0x000000019a97fa8c _pthread_body + 0 
6 libsystem_pthread.dylib   0x000000019a97d028 thread_start + 4 

Vedi questo: iOS 7 and OpenGL issues/crashes ho depositato bug 23.389.472 con mela, causa nel mio caso non si tratta di un filo I o qualche codice 3rd party ha creato, e, questa convenzione, questo è molto probabilmente non è il mio bug. La linea di fondo è: se il thread offendente è tuo (che include ovviamente software di terze parti), allora si applica la risposta di Ryan. Altrimenti hai per contattare Apple e/o, nel frattempo, cercare una soluzione alternativa.