http://code.google.com/p/andengine/source/browse/src/org/anddev/andengine/opengl/view/GLSurfaceView.java
I am not the expert but
I was looking at andengine they have their modified glsurfaceview and they
say something about lockup. I am not sure that's what is happening here. my
2 cents
Thanks
On Tue, Sep 14, 2010 at 10:22 AM, timedilation <udayan.k...@gmail.com>wrote:
> 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<android-developers%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
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
