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
