1.5 quits for apparently no reason whilst animating (WIN DEATH)

  • Replies:6
J R Closs
  • Forum posts: 4

Nov 22, 2010, 4:27:17 PM via Website

I have an app that is working fine in 1.6 and up but crashing for
apparently no reason in 1.5. The app suddenly quits with the following
message...


I/WindowManager( 563): WIN DEATH: Window{43717218
com.bitbull.meat.android/com.bitbull.meat.android.MEATActivity
paused=false}
I/WindowManager( 563): WIN DEATH: Window{4373f458 SurfaceView
paused=false}
D/Zygote ( 541): Process 723 terminated by signal (11)
W/InputManagerService( 563): Got RemoteException sending
setActive(false) notification to pid 723 uid 10019

This error happens when the app is 'idling' (ie not doing anything
other than redrawing the screen). There is no state change and no user
input. The error occurs after the same amount of elapsed time whatever
I set the frame rate of the app to and occurs both on the emulator and
device. Changing what I display on screen can stop the error but there
appears to be no logic to this (in one instance not drawing a large
image stops the error but elsewhere just drawing some text causes the
app to crash in the same manner).

I am using SurfaceView for animations following the basic procedure in
the Lunar Lander sample app.

If anyone could help with this I would be *extremely* grateful as it
has me completely stumped at the moment.

Reply
Jeremiah
  • Forum posts: 775

Nov 23, 2010, 2:27:23 AM via App

Since it is happening when idling, and at the same time every time; it could have to do with some thing that Android changes when there is no user input. Such as maybe the screen time out is occurring causing Android to turn off the screen, which could be changing the state of your surfaceview.

Reply
J R Closs
  • Forum posts: 4

Nov 23, 2010, 4:45:38 PM via Website

Hi,

Thanks for response. Yeah, I thought the same thing, like Android is interrupting the app to do something which is causing it to crash. Question is what? :P

It's not the screen timeout as it occurs after about a second (and I've turned it off anyway).

cheers

Reply
J R Closs
  • Forum posts: 4

Nov 24, 2010, 4:10:11 PM via Website

Hi,

After some more experimentation it appears that this is nothing to do with the drawing per se. The app still crashes even if I just load a fullscreen image at a certain point (though it doesn't actually crash at the moment the image is loaded but about a second after) even if I remove all drawing code and pretty much all run loop code!

This would seem to indicate a heap issue - could Android be shutting down the app because it perceives it to be using too much memory? I have tried setting vm.heapSize for the avd to 64megs and this makes no difference. Also a test app I ran loads ten fullscreen images with no problems (and the app that's crashing loads considerably less than this).

Does this sort of issue ring any bells with anyone? Are there any known limits on java code size, offscreen image size, class code size, size for static variables or anything like this that could be causing me problems?

Still completely stumped and any help appreciated. Stack trace from the crash below if this means anything to anyone...

I/DEBUG ( 539): signal 11 (SIGSEGV), fault addr 00000004
I/DEBUG ( 539): r0 00000004 r1 4001d040 r2 00000004 r3 ad3296c5
I/DEBUG ( 539): r4 00000000 r5 00000000 r6 ad33cce1 r7 41039fb8
I/DEBUG ( 539): r8 100ffd00 r9 41039fb0 10 41039fa0 fp 00000001
I/DEBUG ( 539): ip ad35b874 sp 100ffce8 lr ad3296cf pc afb045a8 cpsr 00000010
I/DEBUG ( 539): #00 pc 000045a8 /system/lib/libcutils.so
I/DEBUG ( 539): #01 lr ad3296cf /system/lib/libandroid_runtime.so
I/DEBUG ( 539): stack:
I/DEBUG ( 539): 100ffca8 00000000
I/DEBUG ( 539): 100ffcac 00000000
I/DEBUG ( 539): 100ffcb0 00000000
I/DEBUG ( 539): 100ffcb4 00000000
I/DEBUG ( 539): 100ffcb8 00000000
I/DEBUG ( 539): 100ffcbc 41f84728
I/DEBUG ( 539): 100ffcc0 00000001
I/DEBUG ( 539): 100ffcc4 41f84728
I/DEBUG ( 539): 100ffcc8 00000001
I/DEBUG ( 539): 100ffccc 00000000
I/DEBUG ( 539): 100ffcd0 00000000
I/DEBUG ( 539): 100ffcd4 410903b0
I/DEBUG ( 539): 100ffcd8 100ffd30
I/DEBUG ( 539): 100ffcdc 00000005
I/DEBUG ( 539): 100ffce0 df002777
I/DEBUG ( 539): 100ffce4 e3a070ad
I/DEBUG ( 539): #00 100ffce8 00000000
I/DEBUG ( 539): 100ffcec ad3296cf /system/lib/libandroid_runtime.so
I/DEBUG ( 539): 100ffcf0 100ffd20
I/DEBUG ( 539): 100ffcf4 ad33ccf1 /system/lib/libandroid_runtime.so
I/DEBUG ( 539): 100ffcf8 4001d040
I/DEBUG ( 539): 100ffcfc ad00e3b8 /system/lib/libdvm.so
I/DEBUG ( 539): 100ffd00 410903b0
I/DEBUG ( 539): 100ffd04 001015a8 [heap]
I/DEBUG ( 539): 100ffd08 ad33cce1 /system/lib/libandroid_runtime.so
I/DEBUG ( 539): 100ffd0c 4001d040
I/DEBUG ( 539): 100ffd10 00001071
I/DEBUG ( 539): 100ffd14 001015a8 [heap]
I/DEBUG ( 539): 100ffd18 100ffd20
I/DEBUG ( 539): 100ffd1c ad040a8d /system/lib/libdvm.so
I/DEBUG ( 539): 100ffd20 41039fb0
I/DEBUG ( 539): 100ffd24 420000f8
I/DEBUG ( 539): 100ffd28 ad33cce1 /system/lib/libandroid_runtime.so
I/DEBUG ( 539): 100ffd2c 100ffd98

Reply
Jeremiah
  • Forum posts: 775

Nov 25, 2010, 12:40:48 AM via App

The vm heapsize is 16mbs for standard devices and 24mbs for hi res devices. You can change it in the emulator, like you said; but this won't help you when on an actual phone. You can't go by the file size of your graphics files for how much memory they use. When loaded in the app they will be uncompressed. A formula you can use is, width*height*color depth. So for a 100x100x24bit color image, it would use about 30k when loaded in memory.

Could you post the full error, with what line number it occurs on and what code is in that line?

— modified on Nov 25, 2010, 12:56:17 AM

Reply
J R Closs
  • Forum posts: 4

Nov 25, 2010, 12:31:32 PM via Website

SOLVED!

The issue appears to have been caused by keeping pointers for drawing on offscreen images.

I have a six or seven small offscreen images in memory that are updated periodically. I was maintaining a Canvas pointer for each of them, e.g.:

Bitmap bitmap = Bitmap.createBitmap( 128, 32, Bitmap.Config.ARGB_8888 );
Canvas canvas = new Canvas( bitmap );

If I stopped holding these canvas objects in memory and instead instantiate a new one each time I need to draw on the offscreen image it works fine.

I wasn't drawing on the images or anything when the crash occurred, but for some reason keeping multiple offscreen Canvas objects in memory seems to cause 1.5 to barf(!)

Very hard to debug as basically I'm working with an entire finished game that has been ported from JavaME using a JavaME->Android 'wrapper' that I've written. No line numbers given for the error as it's a native-level crash, no Java Exception/Error thrown or anything. Increasing the avd heap size made no difference even though this seems, superficially anyway, to be a memory issue.

Thanks for the input!

Reply
Jeremiah
  • Forum posts: 775

Nov 25, 2010, 4:56:04 PM via Website

I had read about this type of thing before (was having out of memory problems with an app too), the reason I heard that keeping canvas pointers to your bitmaps will cause out of memory errors is because the bitmaps never get garbage collected (or removed from memory) as long as a canvas still reference's them.

Glad you got it solved.

Reply