我正在使用NDK(第4版)和OpenGL ES 2.0为Nexus One编写图形密集的游戏。我们真的在这里推动硬件,并且大多数情况下它运行良好,除了每隔一段时间我就会发生严重的崩溃:
W / SharedBufferStack(398):waitForCondition(LockCondition)超时 (identity = 9,status = 0)。 CPU可以挂钩。再试一次。
整个系统锁定,反复重复此消息,并在几分钟后重新启动,或者我们必须手动重启。我们正在使用Android OS 2.1,更新1。
我知道其他一些人已经看到过这个错误,有时与音频有关。在我的情况下,它是由SharedBufferStack
引起的,所以我猜它是一个OpenGL问题。有没有人遇到这个,更好的修复它?或者有人知道SharedBufferStack
发生了什么事情以帮助我缩小范围吗?
答案 0 :(得分:2)
我不相信音频代码中会出现这样的错误,SharedBufferStack仅用于Surface库。很可能这是EGL swapBuffers或SurfaceFlinger实现中的一个错误,您应该将其归档到bug tracker。
答案 1 :(得分:1)
waitForCondition()会导致锁定(系统冻结) 但这不是根本原因。这似乎是
的问题 音频框架(你的游戏有声音吗?)
- 或 -
GL渲染子系统。
日志中是否有“CPU挂钩”消息?
你可能想看看这个:
的 http://soledadpenades.com/2009/08/25/is-the-cpu-pegged-and-friends/ 强>
答案 2 :(得分:1)
我在LogCat上收到CPU may be pegged
条消息,因为我的代码中有ArrayBlockingQueue。如果您有任何阻塞队列(如音频缓冲区的情况),请确保BlockingQueue.put()仅在您具有足够的时序控制以正确BlockingQueue.take()元素为其腾出空间时。或者,请查看使用BlockingQueue.offer()。
答案 3 :(得分:0)
eglSwapBuffers()似乎存在驱动程序问题:
一种解决方法是在致电glFinish()
之前致电eglSwapBuffers()
,但这会导致性能下降。
答案 4 :(得分:0)
FWIW,我最近在三星Galaxy S上使用GL ES 2在Android 2.3.4上进行开发时遇到了这个问题。
对我来说问题是我的glDrawArrays调用中的一个错误 - 我正在渲染超过缓冲区的末尾,即" count"我传入的数字大于实际数量。有趣的是,该调用没有抛出异常,但它会间歇性地导致您描述的问题。另外,我最终渲染的缓冲区看起来不对,所以我知道有些东西已经关闭了。 " CPU可以挂钩"事情只是让追踪真正的问题变得更加烦人。