Nexus One / Android "CPU may be pegged" bug

Question

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?

Conias

By any chance do you see "FAILED BINDER TRANSACTION" in the logcat output? – Extrados

I had the same problem two months ago and I found a way around it (not really a fix), but forgot where it was happening. I was looking around the web, so there should be at least one solution/workaround available. – Eakin

@Shade: Do you remember anything about the workaround itself? – Selfhood

I am pretty sure it was the same problem as observed here. I will try and go through some of my code. If I get lucky I'll post here. – Eakin

Please, keep comments in English. Otherwise it is very hard for others to contribute. – Privett

Have anyone found a solution to this? Please @Kimberly Spreen, could you comment if you've found a solution? – Leeward

Answer 1

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.

Selfhood

Take a look at the link TheCodeArtist posted, and you will see that this error can happen in audio code indeed. – Hothead

Answer 2

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/

Coranto

The link talks about AudioTrack. However, my problem stems from MediaPlayer. – Hothead

Answer 3

I got CPU may be pegged messages 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().

Hamitosemitic

Answer 4

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 to eglSwapBuffers(), however this will induce a performance hit.

Reins

Answer 5

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.

Mattias