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
