[android-developers] Re: Oops, I crashed the phone
On Aug 16, 11:07 pm, Mark Gjøl bitflips...@gmail.com wrote: My drawing loop is strictly single threaded (fed data by several other threads, obviously) I didn't mean that you had multiple drawing threads; I don't either, really. But like you, I do have several threads, that feed the drawing thread. And then OpenGL has a thread of its own, maintained by the system. It's only a hunch on my part that it's a multithreading issue, really. In addition to the error message you posted, the other one I've been able to capture from logcat when the phone locks up is: W/SurfaceComposerClient(11811): lock_layer timed out (is the CPU pegged?) layer=0, lcblk=0x420a4020, state=000e (was 000e) Both messages talk about locking, which says multithreading to me. And I THINK my incidence decreased when I added all the thread-safe code. But it's so intermittent that I can't be sure, and in any case it apparently hasn't gone away completely. So that's not the whole issue. My app has been on the Market for almost a year now, and hasn't had these problems until now. I recently changed a couple of things, the most noteworthy being the ability to use 256x256 textures rather than 128x128. As the crashes are completely random, I cannot be completely certain if this is the problem, but I don't seem to be getting the crashes when sticking to 128x128 textures, so maybe I'm exceeding some secret limit? For the record, aside from some 6 UI buttons at 64x64, I'm using about 9 256x256 textures and a single 1024x1024 texture. I am aware that this can be optimized to use less textures, and that may well be the fix to stop the phone from crashing. Now THAT'S interesting. Like you, my app didn't used to do this, but I'm not entirely sure when it started. It might have been about the time I added a few more textures... mine mostly uses just a few big ones. It's always used two at 1024x512, but this may have started at the same time I added another object with a 512x256 texture. I might try downgrading that one and see how it goes. If you can get away with 128x128 textures, and that solves the problem for you, then I'd say do it. I know, the appearance won't be as good, but trust me... users are far more likely to downrate you for crashing their phone. String -- 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
[android-developers] Re: Oops, I crashed the phone
On Aug 15, 12:46 pm, Mark Gjøl bitflips...@gmail.com wrote: It's always a problem if you can crash the phone. As I'm working with OpenGL I'm guessing this is the problem, as I'm working directly with the hardware. When the phone crashes it hangs for a couple of minutes, Mark, It's not just you. One of my OpenGL apps has been plagued with this problem for a couple of months now, and I've virtually given up on it as unsolvable. I've actually unpublished the free version of this app because so many users were affected, and my fear is that the paid version will ultimately be doomed as well. The thing that makes it just so difficult is that I cannot make it happen with any regularity. I see it on either my G1 or N1 maybe once every couple of weeks, but with no discernible pattern. This makes it essentially impossible to test any proposed fix, because I just can't tell if the problem has gotten any better. You might look at the following old thread, if you haven't already: http://groups.google.com/group/android-developers/browse_frm/thread/f7b6b17b04f93ef3 There is a proposed solution in there that didn't help me, but you might have better luck. There are also a couple of issues in the bugtracker linked from that thread. My best theory is that it's some sort of race condition between the UI and OpenGL threads... I think I was able to reduce (but not eliminate) the occurrences by making my code as thread-safe as possible. Things like: - using the volatile modifier on all variables touched in onDrawFrame() - using synchronize on other functions called from within my OpenGL code - putting a semaphore in onDrawFrame() to ensure that it's only ever got one instance running at a time ...and so on. Good luck with this, and I mean that with all my heart. It's the most dispiriting programming problem I've faced in a long, long time. Please let us know if you get anywhere with it. String -- 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
[android-developers] Re: Oops, I crashed the phone
String, I could try and make sure I'm not drawing to the screen from several places at the same time, but I don't think this is the problem. My drawing loop is strictly single threaded (fed data by several other threads, obviously), so Android would have to be maintaining multiple GL message loops at once. At any rate, I think the problem is more mechanical... My app has been on the Market for almost a year now, and hasn't had these problems until now. I recently changed a couple of things, the most noteworthy being the ability to use 256x256 textures rather than 128x128. As the crashes are completely random, I cannot be completely certain if this is the problem, but I don't seem to be getting the crashes when sticking to 128x128 textures, so maybe I'm exceeding some secret limit? For the record, aside from some 6 UI buttons at 64x64, I'm using about 9 256x256 textures and a single 1024x1024 texture. I am aware that this can be optimized to use less textures, and that may well be the fix to stop the phone from crashing. So I'm not sure the problems are the same, but maybe they're related? - Mark On Aug 16, 9:59 pm, String sterling.ud...@googlemail.com wrote: On Aug 15, 12:46 pm, Mark Gjøl bitflips...@gmail.com wrote: It's always a problem if you can crash the phone. As I'm working with OpenGL I'm guessing this is the problem, as I'm working directly with the hardware. When the phone crashes it hangs for a couple of minutes, Mark, It's not just you. One of my OpenGL apps has been plagued with this problem for a couple of months now, and I've virtually given up on it as unsolvable. I've actually unpublished the free version of this app because so many users were affected, and my fear is that the paid version will ultimately be doomed as well. The thing that makes it just so difficult is that I cannot make it happen with any regularity. I see it on either my G1 or N1 maybe once every couple of weeks, but with no discernible pattern. This makes it essentially impossible to test any proposed fix, because I just can't tell if the problem has gotten any better. You might look at the following old thread, if you haven't already:http://groups.google.com/group/android-developers/browse_frm/thread/f... There is a proposed solution in there that didn't help me, but you might have better luck. There are also a couple of issues in the bugtracker linked from that thread. My best theory is that it's some sort of race condition between the UI and OpenGL threads... I think I was able to reduce (but not eliminate) the occurrences by making my code as thread-safe as possible. Things like: - using the volatile modifier on all variables touched in onDrawFrame() - using synchronize on other functions called from within my OpenGL code - putting a semaphore in onDrawFrame() to ensure that it's only ever got one instance running at a time ...and so on. Good luck with this, and I mean that with all my heart. It's the most dispiriting programming problem I've faced in a long, long time. Please let us know if you get anywhere with it. String -- 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
[android-developers] Re: Oops, I crashed the phone
This is what I get from adb logcat until the phone reboots:
I/ActivityManager( 88): Start proc dk.nindroid.rss for activity
dk.nindroid.rss/.ShowStreams: pid=6295 uid=10046 gids={3003, 1015}
I/global ( 6295): Default buffer size used in BufferedOutputStream
constructor. It would be better to be explicit if an 8k buffer is
required.
D/dalvikvm( 6295): GC_EXTERNAL_ALLOC freed 898 objects / 70704 bytes
in 43ms
D/dalvikvm( 6295): GC_EXTERNAL_ALLOC freed 268 objects / 13416 bytes
in 34ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 4184 objects / 230936 bytes in
48ms
V/Floating Image( 6295): 501 files in cache.
V/Floating Image( 6295): Old version: 2.5.0, current version: 2.5.0
V/Floating Image( 6295): Resuming main activity
D/dalvikvm( 6295): GC_FOR_MALLOC freed 6761 objects / 426352 bytes in
39ms
V/Floating Image( 6295): Begin resume...
V/Floating Image( 6295): Switching to floating renderer
V/Floating Image( 6295): Resume texture bank done...
V/Bitmap downloader( 6295): *** Starting asynchronous downloader
thread
V/Orientation manager( 6295): Resume!
V/Floating Image( 6295): End resume...
V/Floating Image( 6295): Resetting images
V/Floating Image( 6295): Not signed in to Picasa
D/libEGL ( 6295): loaded /system/lib/egl/libGLES_android.so
D/libEGL ( 6295): loaded /system/lib/egl/libEGL_adreno200.so
D/libEGL ( 6295): loaded /system/lib/egl/libGLESv1_CM_adreno200.so
D/libEGL ( 6295): loaded /system/lib/egl/libGLESv2_adreno200.so
V/Display ( 6295): Display surface changed!
V/dk.nindroid.rss.RiverRenderer( 6295): Orientation change received: 0
V/Display ( 6295): Fullscreen is true
I/ActivityManager( 88): Displayed activity
dk.nindroid.rss/.ShowStreams: 1066 ms (total 1066 ms)
V/dk.nindroid.rss.RiverRenderer( 6295): Orientation change received: 2
I/CheckinService( 192): Preparing to send checkin request
I/EventLogService( 192): Accumulating logs since 1281881326137
E/Tethering( 88): active iface (usb0) reported as added, ignoring
D/BatteryWidget( 483): Updating Views
D/dalvikvm( 6295): GC_FOR_MALLOC freed 3732 objects / 397144 bytes in
47ms
V/FeedController( 6295): 4 photos found.
V/Floating Image( 6295): Showing images from 1 feeds
D/dalvikvm( 192): GC_FOR_MALLOC freed 1803 objects / 359704 bytes in
58ms
D/NativeCrypto( 192): Freeing OpenSSL session
I/CheckinTask( 192): Sending checkin request (4569 bytes)
D/dalvikvm( 6295): GC_FOR_MALLOC freed 970 objects / 263552 bytes in
38ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 1038 objects / 226112 bytes in
56ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 515 objects / 236280 bytes in
77ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 733 objects / 225640 bytes in
40ms
I/CheckinTask( 192): Checkin success:
https://android.clients.google.com/checkin
(1 requests sent)
I/CheckinService( 192): From server: Intent
{ act=android.server.checkin.FOTA_CANCEL }
D/dalvikvm( 192): GC_FOR_MALLOC freed 4869 objects / 538856 bytes in
76ms
D/NativeCrypto( 192): Freeing OpenSSL session
D/dalvikvm( 6295): GC_FOR_MALLOC freed 601 objects / 244864 bytes in
43ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 850 objects / 252320 bytes in
45ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 733 objects / 200704 bytes in
49ms
D/dalvikvm( 6295): GC_EXTERNAL_ALLOC freed 152 objects / 61448 bytes
in 40ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 356 objects / 238848 bytes in
77ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 357 objects / 238944 bytes in
59ms
D/dalvikvm( 5388): GC_EXPLICIT freed 217 objects / 11488 bytes in 90ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 352 objects / 238728 bytes in
53ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 352 objects / 238728 bytes in
65ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 352 objects / 238728 bytes in
75ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 352 objects / 238728 bytes in
76ms
D/dalvikvm( 6295): GC_FOR_MALLOC freed 352 objects / 238728 bytes in
62ms
V/dk.nindroid.rss.RiverRenderer( 6295): Orientation change received: 0
W/KeyCharacterMap( 6295): No keyboard for id 65540
W/KeyCharacterMap( 6295): Using default keymap: /system/usr/keychars/
qwerty.kcm.bin
D/MobileDataStateTracker( 88): replacing old mInterfaceName (rmnet0)
with rmnet0 for dun
D/MobileDataStateTracker( 88): replacing old mInterfaceName (rmnet0)
with rmnet0 for hipri
D/MobileDataStateTracker( 88): supl Received state= CONNECTED, old=
CONNECTED, reason= (unspecified), apnTypeList= *
D/MobileDataStateTracker( 88): replacing old mInterfaceName (rmnet0)
with rmnet0 for mms
D/MobileDataStateTracker( 88): default Received state= CONNECTED,
old= CONNECTED, reason= (unspecified), apnTypeList= *
D/NetworkLocationProvider( 88): onDataConnectionStateChanged 3
W/SharedBufferStack( 88): waitForCondition(LockCondition) timed out
(identity=2, status=0). CPU may be pegged. trying again.
W/SharedBufferStack( 88): waitForCondition(LockCondition) timed out
(identity=2, status=0). CPU may be pegged. trying again.
W/SharedBufferStack( 88): waitForCondition(LockCondition) timed out
(identity=2, status=0). CPU may be
