Nexus One/Android "CPU puede estar vinculado" error

Question

Estoy escribiendo un juego gráficamente intenso para el Nexus One, utilizando el NDK (revisión 4) y OpenGL ES 2.0. Realmente estamos empujando el hardware aquí, y en su mayor parte funciona bien, excepto de vez en cuando me sale un accidente grave con este mensaje de registro:

W/SharedBufferStack (398): waitForCondition (LockCondition) se agotó el tiempo de espera (identity = 9, status = 0). La CPU puede estar vinculada. Intentando otra vez.

Todo el sistema se bloquea, repite este mensaje una y otra vez, y se reinicia después de un par de minutos o tenemos que reiniciarlo manualmente. Estamos usando Android OS 2.1, actualización 1.

Conozco a algunas otras personas que han visto este error, a veces en relación con el audio. En mi caso, es causado por el SharedBufferStack, así que supongo que es un problema de OpenGL. ¿Alguien ha encontrado esto y mejor aún lo ha solucionado? ¿O alguien sabe qué está pasando con el SharedBufferStack para ayudarme a reducir las cosas?

Answer 1

No creo que pueda ocurrir tal error en el código de audio, SharedBufferStack solo se usa en bibliotecas de Surface. Lo más probable es que este sea un error en la implementación de EGL swapBuffers o SurfaceFlinger, y debe archivarlo en el bug tracker.

Answer 2

El waitForCondition() provoca el bloqueo (congelación del sistema).
Pero no es la causa raíz. Esto parece ser un problema con

El de audio-marco (ur juego tiene sonidos?)
-o-
El GL representación del subsistema de.

¿Algún mensaje de "CPU-pegged" en el registro? Es posible que desee echar un vistazo a esto:
http://soledadpenades.com/2009/08/25/is-the-cpu-pegged-and-friends/

Answer 3

tengo CPU may be pegged mensajes en LogCat porque tenía un ArrayBlockingQueue en mi código. Si tiene alguna cola de bloqueo (como parece ser el caso con los almacenamientos intermedios de audio), asegúrese de BlockingQueue.put() solo si tiene el control de tiempo suficiente para BlockingQueue.take() elementos adecuados para hacer espacio para ello. O bien, eche un vistazo al uso de BlockingQueue.offer().

Answer 4

Parece que hay un problema con el controlador (eglSwapBuffers):

http://code.google.com/p/android/issues/detail?id=20833&q=cpu%20may%20be%20pegged&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars

Una solución es llamar a glFinish() anteriores a su llamada a eglSwapBuffers(), sin embargo, esto inducirá un impacto en el rendimiento.

Answer 5

Fwiw, me golpeó este tema recientemente, mientras que el desarrollo en Android 2.3.4 usando GL ES 2 en un Samsung Galaxy S.

El problema para mí fue un error en mis glDrawArrays llamar - que estaba más allá del final de renderizado del buffer, es decir, el "conteo" que estaba pasando fue mayor que el recuento real. Curiosamente, esa llamada no generó una excepción, pero de manera intermitente provocaría el problema que usted describió. Además, el búfer en el que terminé la representación se veía mal, así que sabía que algo no funcionaba.La cosa de "CPU puede estar vinculada" simplemente hizo que sea más molesto rastrear el problema real.