使用 EXC_RESOURCE 关闭应用程序，iOS 8 GM 上的 WAKEUPS 异常
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/25848441/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
App shutdown with EXC_RESOURCE, WAKEUPS exception on iOS 8 GM
提问by Coder
Does anyone know what this kind of exception is on iOS 8?
有谁知道 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..
似乎只发生在 iOS 8 上......我们的应用程序以任意时间间隔随机关闭，但此异常..
Any clues are welcome. Thanks!
欢迎提供任何线索。谢谢！
回答by Ryan Kreager
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.
您的应用程序经常向应用程序中的特定线程发送唤醒命令 - 显然平均每秒 206 次。iOS 8 中的后台线程对每秒可以在每个线程上运行睡眠/唤醒周期的次数有严格的限制，这里的计数很高通常表明您的线程管理存在问题/效率低下。
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.
在没有看到你的代码的情况下，我的建议是你检查你的 C++ 算法的睡眠/唤醒调用，或者多线程后台进程以在每个周期启动新线程。
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
Ray Wenderlich 有一篇关于 Apple 多线程系统 Grand Central Dispactch 的精彩教程，这对您来说也可能是一个很好的资源：http://www.raywenderlich.com/60749/grand-central-dispatch-in-depth-part- 1
回答by Alexandre Emond
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.
使用 Xamarin，我们也遇到了这个问题。我们使用了 4 个同时等待太长时间的 SemaphoreSlim。用其他原始同步（在我们的例子中为 AutoResetEvent 来模拟 1 个项目的信号量）替换 SemaphoreSlim 解决了这个问题。
回答by Anton Tropashko
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.
在我的 ios 9.1 上，这被线程 2 绊倒，线程 2 似乎是 GLES 驱动程序的一些工作人员，导致搜索项目源我没有看到任何对 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/crashesI'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.
请参阅： iOS 7 和 OpenGL 问题/崩溃我已经向苹果提交了错误 23389472，因为在我的情况下，这不是我或某些 3rd 方代码创建的线程，因此，这很可能不是我的漏洞。底线是：如果有问题的线程是您的（显然包括 3rd 方软件），那么 Ryan 的回答适用。否则，您必须联系 Apple 和/或同时寻找解决方法。
