Я пишу графически насыщенную игру для Nexus One, используя NDK (версия 4) и OpenGL ES 2.0. Мы действительно подталкиваем оборудование здесь, и по большей части оно работает хорошо, за исключением случаев, когда я получаю серьезный сбой с этим сообщением журнала:
W/SharedBufferStack (398): waitForCondition (LockCondition) вышло из строя (identity = 9, status = 0). ЦП может быть привязан. снова пытается.
Вся система блокируется, повторяет это сообщение снова и снова и будет либо перезапущена через пару минут, либо мы перезагрузим его вручную. Мы используем Android OS 2.1, обновление 1.
Я знаю, что некоторые другие люди видели эту ошибку, иногда по отношению к аудио. В моем случае это вызвано SharedBufferStack, поэтому я предполагаю, что это проблема OpenGL. Кто-нибудь сталкивался с этим, и еще лучше его исправил? Или кто-нибудь знает, что происходит с SharedBufferStack, чтобы помочь мне сузить вещи?
Я не верю, что такая ошибка может возникнуть в звуковом коде, SharedBufferStack используется только в библиотеках Surface. Скорее всего, это ошибка в реализации EGL swapBuffers или SurfaceFlinger, и вы должны записать ее в отслеживатель ошибок.
waitForCondition() вызывает блокировку (системное замораживание).
Но это не главная причина. Это, по-видимому, проблема с
аудио-фреймворк (ур-игра звучит?)
-или-
Подсистема GL-рендеринга.
Любые сообщения с "CPU-pegged" в журнале?
Вы можете взглянуть на это:
http://soledadpenades.com/2009/08/25/is-the-cpu-pegged-and-friends/
Я получил сообщения CPU may be pegged в LogCat, потому что в моем коде был ArrayBlockingQueue. Если у вас есть какая-либо блокирующая очередь (как это происходит с аудио буферами), убедитесь, что BlockingQueue.put(), только если у вас есть выбор времени достаточно контролировать BlockingQueue.take(), чтобы освободить место для него. Или еще, посмотрите на BlockingQueue.offer().
Кажется, проблема с драйвером eglSwapBuffers():
Одним из способов является вызов glFinish(), предшествующий вашему вызову, на eglSwapBuffers(), однако это вызовет удар по производительности.
FWIW, я недавно попал в эту проблему при разработке на Android 2.3.4 с использованием GL ES 2 на Samsung Galaxy S.
Проблема для меня была ошибкой в моем вызове glDrawArrays - я передавал за конец буфера, т.е. "счетчик", который я проходил, был больше фактического счета. Интересно, что этот вызов не вызывал исключения, но он периодически приводил к проблеме, которую вы описали. Кроме того, буфер, в котором я оказался, выглядел неправильно, поэтому я знал, что что-то не работает. "ЦП может быть привязан", это просто раздражало, чтобы отследить реальную проблему.