Social Hub, That's not it. That was just a workaround for 2 sequential activities. This problem is deeper than GLSurfaceView. IMO there is a race condition between some code system_server calls and the userland app which results in mutual freeze. It is up to the platform developers to solve, but our job should be to try to isolate some use cases that really show it well so they can fix it.
On Sep 14, 10:40 am, social hub <shubem...@gmail.com> wrote: > http://code.google.com/p/andengine/source/browse/src/org/anddev/anden... > > 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... > > ) > > > //----------------------------------------- > > 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%2Bunsubs > > cr...@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
