[android-developers] OutOfMemoryError from BitmapFactory
At 2:35 PM -0700 4/30/09, fadden wrote: >The "hprof" dump can help with that. I added a quick writeup: >http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/heap-profiling.html;hb=HEAD Thanks -- I used hprof with a previous layout leakage problem, and I think it is a huge turd on toast -- at least the default HTML output anyway. Lot's of noise and very little insight. Maybe there are better viewers for that data. In fact, that experience tells me that leaking view trees makes a noticeable dent in the regular object heap that is easily seen in ddms. Since this problem is causing none of that, it has to be something else. Hopefully I'll get to run some more experiments today. -- Ward --~--~-~--~~~---~--~~ 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] OutOfMemoryError from BitmapFactory
Thanks for these tips. At 1:14 PM -0700 4/30/09, Streets Of Boston wrote: >In my app, i've been dillegently 'unloading' bitmaps when i need >memory. >- clear any bitmap cache I assume you mean any of my own bitmap caches... >So far, this scheme has served me well. Before i got a lot of OOM- >errors. Now i get a lot less. And, if i still get one, i try to >handle it gracefully. It still seems like Voodo to me. If I have to manually call setImageBitmap(null) it implies (to me) that the image view is not being released in the first place, which means the view hierarchy is not being released, even though I have called finish(). At the moment I am looking for static variables and leaked contexts -- Ward --~--~-~--~~~---~--~~ 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] OutOfMemoryError from BitmapFactory
At 11:23 AM -0700 4/30/09, fadden wrote: >It's possible that it didn't actually jump back down. The event log >shows results from all running processes, not just your app, so you >may be seeing output from other things mixed in. Ah, OK. Now I see a steady increase in my limit and allocs from 1.1 up to about 10 MB when it crashes, and I've got another 3.5 in my regular heap -- still less than 16, but ok, -- so this makes sense, and I hope this thread is useful to others --> you can "leak" and look fine in ddms! But this means that the bitmaps for my startup animations, say, are never getting freed, as are the contents of previous screens. Now, none of this stuff is kept in static variables or anything (he said, though you can be sure he is going to check this yet again!) Is there a way to really really make these things get tossed? There ain't no recycle() on drawable (or animation I think)just bitmaps >(This is why the python script I posted yesterday shows the pid and 5- >char app id on each line.) I seem to have completely missed this post... Thanks -- Ward --~--~-~--~~~---~--~~ 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] OutOfMemoryError from BitmapFactory
At 10:26 PM -0700 4/28/09, fadden wrote: >Well, that's the interesting question: how much memory are you >*actually* spending on bitmaps? While I wait for a crash I can measure, my colleague here points out we use a lot of 9 patches as backgrounds for various fields on our screens. If they go into bitmap storage, and aren't regularly compacted as we move from screen to screen, well, that could suck down a lot of the external heap (and fragment it to boot). Perhaps single large bitmaps we could preload would be better. Is that a nutty hypothesis? -- Ward --~--~-~--~~~---~--~~ 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] OutOfMemoryError from BitmapFactory
>I'm going to try to throw something together in python or C that does
>the number-crunching on the log.
Well, I'm as old as Mark Murphy for cris'sake, so I like to use AWK
for things like this, which seemed a good idea until I remembered it
doesn't support infix bitwise operators. Doh! Guess I'll have to
learn something new sometime...
Oh well, I switched to gawk and did this "aeheap.awk" (android external heap):
BEGIN { FS=","; }
/I\/dvm_gc_info/ {
print $0;
print $4;
innum = substr($4,1,length($4)-2); # strip ] off end
print innum;
inlo = and( innum, 0xFFF );
inhi = and( rshift(innum,12),0xFFF);
print inlo, inhi;
print "Alloc:", lshift( and(inlo,0x1ff),(rshift(inlo,9) * 4));
print "Limit:", lshift( and(inhi,0x1ff),(rshift(inhi,9) * 4));
}
Used thusly:
adb logcat -b events -d | /opt/local/bin/gawk -f aeheap.awk -
I get output that agrees with your example at the end of
http://groups.google.com/group/android-developers/browse_thread/thread/6c90a2c70f3593f1/7974ba6fe0361e91?q=fadden+event+log#7974ba6fe0361e91
if I force the 0x783 value in.
A sample:
I/dvm_gc_info( 1868):
[8320808730293606135,-8914445585825568708,-4006653253327009911,7862064]
7862064]
7862064
1840 1919
Alloc: 1245184
Limit: 1568768
If this seems rational, I will now take out the extra print
statements and run this baby next time my app crashes with OOM.
Thanks
-- Ward
--~--~-~--~~~---~--~~
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] OutOfMemoryError from BitmapFactory
Thanks for this excellent explanation. Weird parallel universe indeed! So, right in the onCreate() of my application object, I went and allocated an 8MB array of bytes, causing the heap to grow to 10MB. I then null the array ref and call gc(), which freed up the allocation but left the heap at 10MB. I thought I was moving the "soft limit" up. My init code runs and starts loading bitmaps left and right for the UI and now it craps out real early, every time. Yipes! I've made things much worse! 04-28 18:01:54.675 D/AppStart ( 1443): memory: T:10756064 - F:8716000 (bytes) 04-28 18:01:54.875 D/dalvikvm( 1443): GC freed 349 objects / 24792 bytes in 108ms 04-28 18:01:55.385 D/dalvikvm( 1443): GC freed 192 objects / 7800 bytes in 92ms 04-28 18:01:55.425 E/dalvikvm-heap( 1443): 115600-byte external allocation too large for this process. So this separate "pile" for bitmaps doesn't grow with the VM heap -- in fact, growing the VM heap made it smaller (I think) because, as you say, that space came out of total 16 MB allocation (?) So what is a good strategy to grab more of my allocation for bitmaps? Preload every single bitmap at startup and keep them around? or? Any insights into how this separate bitmap store behaves (growing/shrinking) is of great interest! I mean, I could always use LESS memory, but dang...it seems like since I am well under-budget 16MB wise, there should be some way to make this work... Thanks -- Ward At 5:05 PM -0700 4/28/09, fadden wrote: >On Apr 28, 1:33 pm, Ward Willats wrote: >> So am I really out of memory or just chasing my tail? > >You're really out of memory. > >Bitmap storage exists in a weird parallel universe. The memory isn't >allocated in the virtual heap, but we act like it is when it comes to >deciding if you're out of memory. The per-VM cap is 16MB. > >(Aside: suppose you have 2MB of stuff, and the "soft limit" is 3MB. >You allocate a bunch of objects until you hit the 3MB mark, then a GC >happens. If you free "enough", the soft limit stays where it is. If >you don't free "enough", the soft limit is advanced. This way we're >not allocating physical memory pages that we don't need, but neither >are we GCing constantly. Choosing the right value for "enough" is >something of an art.) > >If you have, say, 4MB of bitmaps, and you start allocating lots of >objects, you will OOM when you hit 12MB of objects. > >Where things get a little quirky is that the opposite isn't true: if >you run out of memory while allocating a bitmap, we don't GC. Freeing >objects won't help unless the soft limit moves. (I think we can >shrink it now, but I suspect we can only do that if there are no >objects sitting out at the end -- remember, the Dalvik GC doesn't do >compaction at this time, which is the main reason why we have this >somewhat bizarre tiered system.) > >If the bitmaps were proper objects on the virtual heap, this would be >less weird, but there's a fair chance you'd still be running out of >memory at this point. > > --~--~-~--~~~---~--~~ 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] OutOfMemoryError from BitmapFactory
At 12:05 PM -0700 4/28/09, Jon Webb wrote: >I have a clue -- the OutOfMemoryError went away when I set debuggable >to false. Does that help? No joy here, I'm afraid. I really hoped this would be it. (Debuggable changing garbage collection behavior or something...) I just happened to have a section of code that blows up reliably after a opening and then closing the G1 screen. Setting debuggable="false" had no effect. Going into set content view I garbage collect and then I have 972K on a 3.2 MB heap: 04-28 13:00:14.375 setContentView(v) b4 memory: T:3284960 - F:971728 (bytes) But during inflation, ~540ms later: 04-28 13:00:14.915 E/dalvikvm-heap( 677): 62500-byte external allocation too large for this process. 04-28 13:00:14.915 E/( 677): VM won't let us allocate 62500 bytes 04-28 13:00:14.915 D/AndroidRuntime( 677): Shutting down VM 04-28 13:00:14.955 E/AndroidRuntime( 677): Caused by: java.lang.OutOfMemoryError: bitmap size exceeds VM budget 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:290) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.graphics.drawable.Drawable.createFromStream(Drawable.java:635) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.content.res.Resources.loadDrawable(Resources.java:1454) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.content.res.Resources.getDrawable(Resources.java:498) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.graphics.drawable.StateListDrawable.inflate(StateListDrawable.java:143) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.graphics.drawable.Drawable.createFromXmlInner(Drawable.java:716) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.graphics.drawable.Drawable.createFromXml(Drawable.java:667) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.content.res.Resources.loadDrawable(Resources.java:1439) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.content.res.TypedArray.getDrawable(TypedArray.java:520) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.view.View.(View.java:1674) 04-28 13:00:14.955 E/AndroidRuntime( 677): at android.view.View.(View.java:1622) 04-28 13:00:14.955 E/AndroidRuntime( 677): ... 31 more I don't see the system (1.1) garbage collecting or trying to grow the heap though when it gets into this kind of trouble... A full release build (with logging off and debuggable off and javac debug off) also blows up in the same way. So am I really out of memory or just chasing my tail? This is a big screen, for sure. But then, the system loaded it once, then again in landscape -- then blew up the third time going back to portrait. I am forcing a garbage collect each onResume(), ddms shows the heap steady-states through all this -- no obvious leakage. -- Ward --~--~-~--~~~---~--~~ 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] OutOfMemoryError from BitmapFactory
Like many others here I'm getting OutOfMemoryError from BitmapFactory when decoding multiple bitmaps. I am sure I am not leaking memory. Here is the system log from a crash: I/dalvikvm-heap( 501): Grow heap (frag case) to 8.731MB for 1357499- byte allocation I/ActivityManager( 82): Process com.android.vending (pid 333) has died. D/dalvikvm( 501): GC freed 7 objects / 248 bytes in 164ms D/CameraService( 32): getParameters V/QualcommCameraHardware( 32): getParameters: EX E/Camera ( 501): _getParameters: antibanding=auto;antibanding- values=off,50hz,60hz,auto;effect- values=mono,negative,solarize,pastel,mosaic,resize,sepia,posterize,whiteboard,blackboard,aqua;jpeg- quality=100;jpeg-thumbnail-height=384;jpeg-thumbnail-quality=30;jpeg- thumbnail-width=512;luma-adaptation=0;nightshot-mode=0;picture- format=jpeg;picture-size=2048x1536;preview-format=yuv422sp;preview- frame-rate=15;preview- size=480x320;rotation=0;whitebalance=auto;whitebalance- values=auto,custom,incandescent,fluorescent,daylight,cloudy,twilight,shade D/dalvikvm( 501): GC freed 204 objects / 1415776 bytes in 140ms E/dalvikvm-heap( 501): 778240-byte external allocation too large for this process. E/( 501): VM won't let us allocate 778240 bytes D/skia( 501): allocPixelRef failed W/dalvikvm( 501): threadid=15: thread exiting with uncaught exception (group=0x 4000fe68) E/AndroidRuntime( 501): Uncaught handler: thread Thread-8 exiting due to uncaught exception E/AndroidRuntime( 501): java.lang.OutOfMemoryError: bitmap size exceeds VM budget As you can see the heap was just grown to 8.731 MB, which is much less than the 16 MB allowed, and much less than the maximum memory this same program has routinely used -- over 10 MB. Just prior to the failed allocation of 778,240 bytes GC freed 1,415,776 bytes. So there should be plenty of memory available. I am scrupulously recycling bitmaps nulling pointers, etc. Any ideas what's going on, or for a workaround? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
