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
