That GLSurfaceView did not fix the issue. The freezing is still happening. I even tried to interrupt() the GLThread from a second thread - no success so far.
On Sep 14, 1:46 pm, Robert Green <rbgrn....@gmail.com> wrote: > 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 > > ... > > read more » -- 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
