Nexus One / Android“CPU 可能被挂钩”漏洞
我正在使用 NDK（修订版 4）和 OpenGL ES 2.0 为 Nexus One 编写一款图形密集型游戏。我们真的在这里推动硬件，并且在大多数情况下它运行良好，除了偶尔我会因以下日志消息而严重崩溃：
W/SharedBufferStack(398): waitForCondition(LockCondition) 超时 （身份=9，状态=0）。 CPU可能被固定。再试一次。
整个系统锁定，一遍又一遍地重复此消息，并且将在几分钟后重新启动，或者我们必须手动重新启动它。我们使用的是 Android 操作系统 2.1，更新 1。
我知道其他一些人也看到了这个错误，有时与音频有关。就我而言，这是由 SharedBufferStack 引起的，所以我猜测这是一个 OpenGL 问题。有没有人遇到过这个问题，并且更好地修复它？或者有谁知道 SharedBufferStack 发生了什么来帮助我缩小范围？
I'm writing a graphically intense game for the Nexus One, using the NDK (revision 4) and OpenGL ES 2.0. We're really pushing the hardware here, and for the most part it works well, except every once in a while I get a serious crash with this log message:
W/SharedBufferStack( 398): waitForCondition(LockCondition) timed out
(identity=9, status=0). CPU may be pegged. trying again.
The entire system locks up, repeats this message over and over, and will either restart after a couple minutes or we have to reboot it manually. We're using Android OS 2.1, update 1.
I know a few other people out there have seen this bug, sometimes in relation to audio. In my case it's caused by the SharedBufferStack, so I'm guessing it's an OpenGL issue. Has anyone encountered this, and better yet fixed it? Or does anyone know what's going on with the SharedBufferStack to help me narrow things down?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不相信这样的错误会发生在音频代码中，SharedBufferStack 仅在 Surface 库中使用。这很可能是 EGL swapBuffers 或 SurfaceFlinger 实现中的错误，您应该将其归档到 错误跟踪器。
I don't believe such error can occur in audio code, SharedBufferStack is only used in Surface libraries. Most probably this is a bug in EGL swapBuffers or SurfaceFlinger implementation, and you should file it to the bug tracker.
我在 LogCat 上收到
CPU may be pegged消息，因为我有一个 ArrayBlockingQueue 在我的代码中。如果您有任何阻塞队列（音频缓冲区似乎就是这种情况），请务必BlockingQueue.put() 仅当您有足够的时间控制来正确 BlockingQueue.take() 元素为其腾出空间。或者，看看使用 BlockingQueue.offer()。I got
CPU may be peggedmessages on LogCat because I had a ArrayBlockingQueue in my code. If you have any blocking queue (as seems to be the case with audio buffers), be sure to BlockingQueue.put() only if you have timing control enough to properly BlockingQueue.take() elements to make room for it. Or else, have a look on using BlockingQueue.offer().waitForCondition() 导致锁定（系统冻结）。
但这不是根本原因。 的问题
这似乎是音频框架 （你的游戏有声音吗？）
-或-
GL 渲染子系统。
日志中是否有“CPU-pegged”消息？
您可能想看看这个：
http://soledadpenades.com/2009 /08/25/is-the-cpu-pegged-and-friends/
The waitForCondition() causes the lockup (system-freeze).
But it is not the root-cause. This seems to be a issue with
The audio-framework (ur game has sounds?)
-or-
The GL rendering-subsystem.
Any "CPU-pegged" messages in the log?
You might want to take a look at this:
http://soledadpenades.com/2009/08/25/is-the-cpu-pegged-and-friends/
eglSwapBuffers() 似乎存在驱动程序问题：
http://code.google.com/p/android/issues/detail?id=20833&q=cpu%20may%20be%20pegged& ;colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
一种解决方法是在调用
eglSwapBuffers()之前调用glFinish()，但是这会导致性能下降。There seems to be a driver problem with eglSwapBuffers():
http://code.google.com/p/android/issues/detail?id=20833&q=cpu%20may%20be%20pegged&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
One workaround is to call
glFinish()preceding your call toeglSwapBuffers(), however this will induce a performance hit.FWIW，我最近在三星 Galaxy S 上使用 GL ES 2 在 Android 2.3.4 上进行开发时遇到了这个问题。
对我来说，问题是我的 glDrawArrays 调用中的一个错误 - 我正在渲染超过缓冲区的末尾，即“计数” “我传入的数字比实际数字要多。有趣的是，该调用没有引发异常，但它会间歇性地导致您所描述的问题。另外，我最终渲染的缓冲区看起来不对，所以我知道有些地方出了问题。 “CPU 可能被固定”的事情只会让追踪真正的问题变得更加烦人。
FWIW, I hit this issue recently while developing on Android 2.3.4 using GL ES 2 on a Samsung Galaxy S.
The issue for me was a bug in my glDrawArrays call - I was rendering past the end of the buffer, i.e. the "count" I was passing in was greater than the actual count. Interestingly, that call did not throw an exception, but it would intermittently result in the issue you described. Also, the buffer I ended up rendering looked wrong so I knew something was off. The "CPU may be pegged" thing just made it more annoying to track down the real issue.