atom feed32 messages in[android-developers] Re: Allocation t...
FromSent OnAttachments
Zach HobbsSep 12, 2008 1:38 pm 
TimOct 26, 2008 7:54 pm 
Romain GuyOct 26, 2008 8:15 pm 
JPOct 26, 2008 8:15 pm 
blindfoldOct 27, 2008 1:54 am 
EboMikeNov 12, 2008 9:09 pm 
blindfoldNov 13, 2008 2:11 am 
EboMikeNov 14, 2008 10:56 pm 
blindfoldNov 15, 2008 12:54 am 
Romain GuyNov 15, 2008 1:01 am 
blindfoldNov 15, 2008 1:30 am 
blindfoldNov 15, 2008 1:54 am 
Romain GuyNov 15, 2008 11:09 am 
blindfoldNov 15, 2008 12:11 pm 
EboMikeNov 16, 2008 11:00 am 
Romain GuyNov 16, 2008 11:12 am 
EboMikeNov 16, 2008 11:32 am 
Romain GuyNov 16, 2008 12:01 pm 
EboMikeNov 16, 2008 12:34 pm 
EboMikeNov 29, 2008 4:13 pm 
fala70Dec 10, 2008 4:00 pm 
Mark MurphyDec 10, 2008 4:03 pm 
Romain GuyDec 11, 2008 4:51 am 
fala70Dec 11, 2008 10:09 am 
Xavier MathewsDec 11, 2008 10:18 am 
Justin (Google Employee)Dec 11, 2008 10:38 am 
EboMikeDec 11, 2008 3:02 pm 
fala70Dec 11, 2008 3:12 pm 
EboMikeDec 11, 2008 3:53 pm 
fala70Dec 11, 2008 5:17 pm 
Justin (Google Employee)Dec 12, 2008 9:46 am 
EboMikeDec 12, 2008 9:51 am 
Subject:[android-developers] Re: Allocation too large for this process
From:EboMike (
Date:Nov 16, 2008 12:34:06 pm

I'm reading JPGs off the storage device, and they are typically 1024x768 since they came straight from a server. The VM typically errors out allocating ~1MB of memory. (One time, it errored allocating 30KB even though the gc freed up 900KB just prior to that).

Yeah, I could have the server crunch the image to 480x320 first, but I'd like to reserve the option to add a zoom function later. Besides, it DOES work most of the time, and if I really have a 16MB heap, there shouldn't be any issues whatsoever.

By the way, it does seem like there might be a leak - in the "data object" row in the Heap DDMS view, I seem to be leaking 10KB or so with every image. How can I track down what's going on there? Like I mentioned earlier, my BitmapDrawables are deleted properly according to the allocation tracker.


On Nov 16, 12:02 pm, Romain Guy <> wrote:

What is the size of the Bitmap you are trying to create?

On Sun, Nov 16, 2008 at 11:33 AM, EboMike <> wrote:

Um, yes... except that I'm randomly getting OutOfMemoryExceptions when I create a new bitmap :)

On Nov 16, 11:13 am, Romain Guy <> wrote:

16 MB is the maximum limit of the heap. Your app can use at most 16 MB.  The heap in your application will grow as more memory is needed. If you're currently at 3/4 MB, then everything's fine :))

On Sun, Nov 16, 2008 at 11:00 AM, EboMike <> wrote:

Thanks for your answer, Romain!

How much of those 16MB are accessible to the app? When I look at the Heap view in the DDMS, I only see one heap with a total size of 3MB, sometimes 4MB. If I add up all the allocations (either in the VM Heap or the allocation tracker), I don't get anywhere near 16 MB. I also don't see any major allocation from the drawables themselves other than 16KB for the BufferedInputReader and BitmapFactory per drawable - is the bitmap data being allocated by native code and invisible to the VM allocation tracker?

After a gc, Runtime.getRuntime().freeMemory() typically gives me numbers between 600KB and 800KB at any given point while I have the Gallery up.

It also seems that I'm not leaking any drawables, at least judging by the number of BitmapDrawable/Bitmap/BufferedInputRead/BitmapFactory objects I have in the allocation tracker - they match the amount of visible views in my gallery.


On Nov 15, 1:01 am, Romain Guy <> wrote:

Applications have a hard limit of 16 MB. As for the other bug you mention, it has nothing to do with memory usage; the implementation of BitmapFactory that reads images from URL will fail over slow connections. Besides, when you load a Drawable from the resources, it simply calls the BitmapFactory to decode the resource anyway.

If you hit an out of memory exception, your app *is* using too much memory (which you might very well be "leaking," it's not that hard, especially if you use static fields in your code.) You can use DDMS and its allocation tracker, as well as its various GC/heap monitors to see when and how your application is allocating so much memory.

I have run myself into this issue several times over the past 18 months and every time, the application was leaking something (especially on screen rotation.)

On Sat, Nov 15, 2008 at 12:55 AM, blindfold <> wrote:

Well Mike, I don't know either, but just remember from my own app that I too had a zillion unexplained "Clamp target GC heap" messages at that 16 MB limit (while my app definitely needs far less memory than that), until I got rid of Drawables altogether. It could have been a coincidence, but together with the report from a Google Android Team member
that "this is a known bug" (without being more specific) and his Drawable- free workaround it suggested that this could be related to your problem. Of course there are plenty of other things that could be wrong...

This is for an ImageSwitcher, so I need a Drawable of some sort

I have never used ImageSwitcher myself (Android seems to often offer at least three totally different ways to do the same thing, which is nice if two-out-of-three are still too buggy for deployment <g>). Yet to avoid Drawables there I could imagine trying ImageSwitcher.setImageURI(new ContentURI("/data/data/mypackage/files/ myimage.jpg")) if the image is in internal flash, or ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/ myimage.jpg")) when loading from SD card. Just my two cent guess.


On Nov 15, 7:57 am, EboMike <> wrote:

Hey blind, you're right, I'm using Drawables -- BitmapDrawables, to be precise. This is for an ImageSwitcher, so I need a Drawable of some sort (since I'm loading jpeg images off the storage device, so I can't use resources). I've tried BitmapFactory.decodeFile() instead of BitmapDrawables constructor that takes a String, but I get the same result, except that the OutOfMemoryException is now in BitmapFactory.decodeFile() itself instead of a cryptic callstack like before.

I also call the gc right before creating the Bitmap... and the TTY is kind of interesting:

06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from 17.019MB to 16.000MB 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224 bytes in 171ms 06:50:45.271: ERROR/dalvikvm-heap(6039): 38400-byte external allocation too large for this process. 06:50:45.271: ERROR/(6039): VM won't let us allocate 38400 bytes 06:50:45.280: DEBUG/skia(6039): xxxxxxxxxxxxxxxxxxxx allocPixelRef failed

The gc freed 927KB, and then cannot allocate 38KB? Um, what?