App shutdown with EXC_RESOURCE, WAKEUPS exception on iOS 8 GM

Question

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

=== from crash report ===

Exception Type: EXC_RESOURCE
Exception Subtype: WAKEUPS
Exception Mes         


        

Answer 1

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.

Answer 2

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

Answer 3

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.