Ошибка процессора "Nexus One / Android " может быть привязана

Question

Ошибка процессора "Nexus One / Android " может быть привязана

Я пишу графически насыщенную игру для 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 чтобы помочь мне сузить дело?

15

android android-ndk nexus-one

Источник

user375511 24 июн '10 в 17:16

5 ответов

Другие вопросы по тегам android android-ndk nexus-one

user2504283 25 июн '10 в 07:46 2010-06-25 07:46 · Answer 1 · 2010-06-25 07:46

Я не верю, что такая ошибка может возникнуть в аудиокоде, SharedBufferStack используется только в библиотеках Surface. Скорее всего, это ошибка в реализации EGL swapBuffers или SurfaceFlinger, и вы должны отправить ее в систему отслеживания ошибок.

2

Источник

user2504283 25 июн '10 в 07:46

user397244 22 май '11 в 18:42 2011-05-22 18:42 · Answer 2 · 2011-05-22 18:42

Я получил CPU may be pegged сообщения на LogCat, потому что в моем коде был ArrayBlockingQueue. Если у вас есть какая-либо блокирующая очередь (как, по-видимому, и в случае аудиобуферов), убедитесь, что BlockingQueue.put () используется только в том случае, если у вас достаточно контроля времени, чтобы должным образом элементы BlockingQueue.take () освободили место для него. Или же, посмотрите на использование BlockingQueue.offer ().

user319204 14 апр '11 в 12:22 2011-04-14 12:22 · Answer 3 · 2011-04-14 12:22

WaitForCondition() вызывает блокировку (заморозка системы).
Но это не первопричина. Это похоже на проблему с

Аудио-фреймворк (в твоей игре есть звуки?)
-или же-
Рендеринг-подсистема GL.

Какие-либо сообщения с привязкой к процессору в журнале? Возможно, вы захотите взглянуть на это:
http://soledadpenades.com/2009/08/25/is-the-cpu-pegged-and-friends/

user1739480 18 дек '12 в 05:23 2012-12-18 05:23 · Answer 4 · 2012-12-18 05:23

Кажется, есть проблема с драйвером eglSwapBuffers ():

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

Один обходной путь должен позвонить glFinish() предшествующий вашему звонку eglSwapBuffers()Однако это вызовет снижение производительности.

0

Источник

user1739480 18 дек '12 в 05:23

user1135394 20 июл '14 в 04:41 2014-07-20 04:41 · Answer 5 · 2014-07-20 04:41

Кстати, я недавно столкнулся с этой проблемой при разработке под Android 2.3.4 с использованием GL ES 2 на Samsung Galaxy S.

Для меня проблемой была ошибка в моем вызове glDrawArrays - я выполнял рендеринг за концом буфера, то есть "количество", которое я передавал, было больше, чем фактическое значение. Интересно, что этот вызов не вызвал исключение, но он периодически приводил к проблеме, которую вы описали. Кроме того, буфер, который я закончил рендерингом, выглядел неправильно, поэтому я знал, что что-то не так. То, что "CPU может быть привязан", просто раздражало отследить реальную проблему.