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