49

Does anyone know what this kind of exception is on iOS 8?

=== from crash report ===

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

Seems to only happen on iOS 8... Our app is shut down quite randomly at arbitrary intervals with this exception..

Any clues are welcome. Thanks!

Coder
  • 491
  • 1
  • 4
  • 3
  • Any luck with this? I am getting the same error with the culprit being: `Thread 4 name: WebThread` – ohhh Sep 21 '14 at 17:10
  • I have exactly the same error. Using Xamarin and OpenTok – Alex Sorokoletov Oct 06 '14 at 00:48
  • We are having a similar problem with our app that may be related with what Ryan said below. Basically we are playing sound effects using SKAction playSoundFileNamed: but sometimes, randomly, it doesn't play any sound unless you exit the app and resume it later, then it plays all at once, which suggest that something is blocking those actions... if you keep playing in this state for a while you will eventually see this crash... – gzafra Oct 16 '14 at 11:33
  • iOS9 added Exception Note: NON-FATAL CONDITION (this is NOT a crash) but it seems to get evicted all the same (I'm not completely sure: I get evicted ALL the time on ios9 and yet have seen this crash report only once). – Anton Tropashko Sep 28 '15 at 12:55

3 Answers3

19

Your app is sending a wakeup command to a particular thread in the app quite often - apparently an average of 206 times a second. Background threads in iOS 8 have a hard limit on how many times you can run a sleep/wake cycle on each thread per second, and having a high count here is usually an indication that something is wrong / inefficient in your thread management.

Without seeing your code, my recommendation is that you check your C++ algorithms for sleep/wake calls, or multithread the background process to start new threads each cycle.

Ray Wenderlich has a fantastic tutorial on Apple's system for multithreading, Grand Central Dispactch, which might also be a good resource for you: http://www.raywenderlich.com/60749/grand-central-dispatch-in-depth-part-1

Ryan Kreager
  • 3,571
  • 1
  • 20
  • 35
2

Using Xamarin, we got this issue too. We were using 4 SemaphoreSlim that were waiting at the same time for a too long period of time. Replacing the SemaphoreSlim by an other primitive synchronization (AutoResetEvent in our case to simulate a Semaphore of 1 item) fixed the issue.

0

In my case on ios 9.1 this is tripped by thread 2 which seems to be some worker for the GLES driver cause searching through the project sources I don't see any references to 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

See this: iOS 7 and OpenGL issues/crashes I've filed bug 23389472 with apple, cause in my case this ain't a thread I or some 3rd party code has created, and, thusly, this is very likely ain't my bug. Bottom line is: if the offending thread is yours (that includes 3rd party software obviously) then Ryan's answer applies. Otherwise you either have to contact Apple and/or, in the meantime, look for a workaround.

Community
  • 1
  • 1
Anton Tropashko
  • 5,486
  • 5
  • 41
  • 66