Any resolutions or workarounds so far on the freezing issue? I am seeing the same with my opengl app - mainly on HTC phones. I have never seen this happen on my G1 though and also never on the Motorola Droid. I am using Google recommended GLSurfaceView and all the standard stuff but the game itself is graphically fairly intensive.
In my case too I get the same messages in logcat: WARN/SharedBufferStack(3878): waitForCondition(LockCondition) timed out ...... CPU may be pegged. trying again. This is what I have found from my own analysis thus far: Apparently the following code from SharedBufferStack.h must be causing these messages to be logged: //---------------------------------------- template <typename T> status_t SharedBufferBase::waitForCondition(T condition) { const SharedBufferStack& stack( *mSharedStack ); SharedClient& client( *mSharedClient ); const nsecs_t TIMEOUT = s2ns(1); Mutex::Autolock _l(client.lock); while ((condition()==false) && (stack.identity == mIdentity) && (stack.status == NO_ERROR)) { status_t err = client.cv.waitRelative(client.lock, TIMEOUT); // handle errors and timeouts if (CC_UNLIKELY(err != NO_ERROR)) { if (err == TIMED_OUT) { if (condition()) { LOGE("waitForCondition(%s) timed out (identity= %d), " "but condition is true! We recovered but it " "shouldn't happen." , T::name(), stack.identity); break; } else { LOGW("waitForCondition(%s) timed out " "(identity=%d, status=%d). " "CPU may be pegged. trying again.", T::name(), stack.identity, stack.status); } } else { LOGE("waitForCondition(%s) error (%s) ", T::name(), strerror(-err)); return err; } } } return (stack.identity != mIdentity) ? status_t(BAD_INDEX) : stack.status; } //---------------------------------------- The GL thread hangs indefinitely while doing the eglSwapBuffer() call. This java call maps to a JNI C++ call via the function below: (taken from this link: http://www.netmite.com/android/mydroid/frameworks/base/opengl/libGLES_CM/gl_wrapper.cpp) //----------------------------------------- EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw) { if (!validate_display_surface(dpy, draw)) return EGL_FALSE; egl_display_t const * const dp = get_display(dpy); egl_surface_t const * const s = get_surface(draw); return s->cnx->hooks->egl.eglSwapBuffers(dp->dpys[s->impl], s- >surface); } //----------------------------------------- The last line of this function I believe hooks into and makes a low level call into the GL driver library on the device. Somewhere in there might be a call that locks up and causes the main thread of my game to start spitting out those timeout (LockCondition) messages to logcat. On Sep 13, 6:24 pm, Jeremy Statz <jst...@gmail.com> wrote: > What I did to log this is to create a special logging class that can > output to SD card, then put a print at the top and bottom of every > function call in my wallpaper, with a fluch() after every line being > written. This wrecks the framerate and results in a several hundred > meg log after a few hours, but means I have a reliable log of all > activity throughout the application. Consistently, the crash occurs > in-between frames, and requires no special stimulation -- the phone > can just be sitting there running, then will suddenly die without > warning. I'm confident saying that. > > I've actually been using your GLWallpaperService code as a base, > though I've made a couple minor changes. It's been quite stable > overall. The big problem here, in my eyes, is that this appears to > affect any OpenGL using application, and is tremendously discouraging, > to the point that people pull things off the market and avoid using > OpenGL. This hurts the platform as a whole, especially when comparing > its game library to the iPhone. > > On top of that, while this seemed exceedingly uncommon on 2.1, I feel > like I've seen a whole lot more of it with 2.2 on my HTC Incredible. > Considering the free versions of my wallpapers have something like > three or four million downloads between them, that scares me a great > deal. That's a lot of potentially affected users. > > On Sep 13, 3:22 am, Robert Green <rbgrn....@gmail.com> wrote: > > > > > Jeremy, > > > It happened to me quite a bit on both 2.1 and 2.2 on every device. > > It's surely a defect of Android but so far no one has been able to > > track it down. It's a tough one, very difficult to reproduce > > reliably. It tends to happen more often in certain cases for reasons > > unknown to me right now, such as on an EVO running 2.1 on the third > > level of Deadly Chambers if you play it straight through. Since that > > takes 20 minutes, it's impossible to figure out by logging because > > it's just way too much. Breakpoints don't work because the game > > doesn't run fast enough in debug mode and debugging doesn't work > > anyways once the lockup has happened. > > > It's pretty much a worse case scenario - a very fatal, very > > intermittent bug that breaks debugging and is nearly impossible to > > isolate. > > > I hope some genius out there can figure this one out. I couldn't even > > get close. > > > On Sep 12, 10:34 pm, Jeremy Statz <jst...@gmail.com> wrote: > > > > There's been a couple threads about this in the last year or so, but I > > > wanted to draw attention to it again, as I've spent most of the last > > > couple of days trying to confirm it wasn't anything I'm doing. > > > > The short story is, I'm pretty sure there's a very serious lock-up-the- > > > phone level bug that happens when using OpenGL applications. When it > > > occurs the phone will freeze for at least two minutes before rebooting > > > itself, sometimes requiring that the battery be pulled. This didn't > > > seem to happen often on 2.1, but I'm seeing it with a lot more > > > regularity on 2.2 (particularly on HTC phones, though that may be a > > > coincidence) and am really hoping to draw some attention from someone > > > in a position to fix it. Typically, you'll end up seeing hundreds of > > > lines of this in the LogCat log: > > > > WARN/SharedBufferStack(2005): waitForCondition(LockCondition) timed > > > out (identity=9, status=0). CPU may be pegged. trying again. > > > WARN/SharedBufferStack(71): waitForCondition(LockCondition) timed out > > > (identity=9, status=0). CPU may be pegged. trying again. > > > > There won't be any callstack or error of any kind preceding this. In > > > this case 2005 is my app (a live wallpaper), and 71 appears to be the > > > UI/system process. I'm assuming this is a race condition within > > > SharedBufferStack. I've seen cases where four or five process IDs > > > were all printing the message, all OpenGL apps of some kind. > > > > Replicating the problem is very, very difficult and seems very > > > random... in the last case I had to leave the wallpaper running and > > > active on the home screen for about seven hours before it occurred. > > > Sometimes I've had it go days, other times it'll happen within a few > > > minutes. My log output demonstrates no unusual activity at all before > > > the crash, loading/unloading/visibility/etc doesn't seem to be a > > > factor. It's very rare. > > > > I kind of feel like this got glossed over the last couple times people > > > have reported it here, but based on my reading it's a long-standing > > > problem with Android and OpenGL and is having a chilling effect on its > > > usage. Is there anyone who can explain if there's anything I can do > > > to discourage problems here? This is beyond my ken honestly, does > > > anyone know this part of the system well? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en