There is bug in BitmapFactory memory allocation, there are tons of
threads in this mailing list dealing with that.
To sum up:
At a normal time when you create an object, the heap size is
automatically grown if not sufficient enough (there is an absolute
limit of 16MB per process though, you will crash if you exceed this).
But the bitmap factory allocates memory in a non Java way, it uses
native code to do that, and the heap growing process fails if not
enough memory in this case!
So even if you are far under the 16MB limit, if you are unlucky enough
to have the heap grown up for your image to be allocated, you will
have an OutOfMemoryError....
Some guys claim that this crash can be avoided by catching this error
(catching an error instead of an exception is quite unusual by the
way)...
On Jan 18, 12:31 am, EboMike <ebom...@gmail.com> wrote:
> Hey gym,
>
> 1) You don't have to go that far. No need to close or reset anything,
> simply run the app from within the emulator (obviously, you need to
> update it via adb install -r or something if you changed it). It will
> show up in the process list in the DDMS, but you'll see that it
> doesn't have that cute bug next to it. You can still add the heap
> watch to it, this will not affect anything. And you can always attach
> the debugger later if you need to debug something -- if you have the
> heap watch on too, you might be able to see a change in behavior as
> soon as you attach it. In my test app that repeatedly called
> BitmapFactory.decodeFile and/or threw an exception, I noticed an
> immediate continual increase in memory usage until it OOMed.
>
> 2) You won't necessarily see any garbage collection until the VM
> decides to collect. That's okay. It doesn't matter if your app takes
> up 15MB without ever collecting garbage. But as soon as you do an
> allocation that exceeds the amount of available RAM, the gc should
> kick in and take out the trash. Basically, it's all good as long as
> you don't OOM. If you OOM, something went wrong.
>
> Please note the very beginning of this thread - there is a known
> problem in the Gallery class, it never recycles its views. However, I
> have an app that uses two Galleries, both of them using
> BitmapFactory.decodeFile(). I've run it on my device, sometimes with
> 1000 entries in the Gallery and scrolling like crazy, and I've never
> OOMed. If I have the debugger attached, I OOM pretty quickly.
>
> 3) Interesting. SHOULDN'T happen, the VM should automatically gc as
> soon as you're running out of memory.
>
> Are you doing anything funky with your Bitmap/Drawable objects? How do
> you manage them?
>
> On Jan 17, 9:03 am, gymshoe <gyms...@bresnan.net> wrote:
>
> > I have noted the following discrepancies compared to the descriptions
> > here, using a similar, simple application which uses Gallery, and
> > BitmapFactory:
>
> > 1) EboMike, How exactly do I run the application "without a debugger
> > attached"? I assume that closing Eclipse entirely, and launching a
> > new emulator from a DOS prompt (without Eclispe running) would be the
> > equivalent of not having a debugger attached.
>
> > When I do this, I get the same memory leak problem as I always did...
>
> > 2) When I have the DDMS attached and running, the heap size doesn't
> > show any garbage collection (see below) going on for my gallery
> > application (unless I click on "Cause GC")...
>
> > 3) If I call System.GC() intermittently directly in my application
> > (calling this method alone, and not as part of a {gc() /
> > runFinalization() / gc()} sequence), this prevents OOM, and then I can
> > see the GC altering the heap size (in DDMS).
>
> > Jim
>
> > On Jan 9, 6:37 pm, fadden <fad...@android.com> wrote:
>
> > > On Jan 9, 4:47 pm, Mark K <mark.ka...@gmail.com> wrote:
>
> > > > I've tried it with no de-bugger, on the emulator, and on actual G1
> > > > hardware, I can't seem to get rid of the problem entirely. I only
> > > > process and use one bitmap at a time, bitmaps are recycled after use,
> > > > and I invoke gc(). The Runtime free memory indicates that I always
> > > > have over 10 MB free, each bitmap is less than 3.5 MB, yet this
> > > > problem still ocurs intermittently.
>
> > > What does logcat show at the point of the failure? Should see some
> > > additional traffic, e.g.:
>
> > > 01-09 16:13:02.739 D/dalvikvm( 178): GC freed 494 objects / 31264
> > > bytes in 265ms
> > > 01-09 16:13:02.829 I/dalvikvm-heap( 178): Grow heap (frag case) to
> > > 4.558MB for 998301-byte allocation
> > > 01-09 16:13:03.039 D/dalvikvm( 178): GC freed 133 objects / 6192
> > > bytes in 196ms
>
> > > Bitmap allocations are done outside of the virtual heap, but are
> > > counted against it. This was done somewhat late in the game and not
> > > all of the tools will include the bitmap heap allocation numbers in
> > > with the actual virtual heap allocations. If you're getting an OOM
> > > you should see it bumping up against the 16MB limit in the logs.
>
> > > FWIW, the only thing worse than explicit calls to System.gc() is
> > > following those with explicit calls to System.runFinalization(), which
> > > in Dalvik will block until finalizers have completed. If your
> > > allocations are somehow outpacing the ability of the system to GC then
> > > finalize then GC again to free the finalized objects, you can stick a
> > > runFinalization() in between a pair of calls to gc(). However, if
> > > you're explicitly calling recycle(), this shouldn't do much since the
> > > bitmap storage should have been released.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
