Guillaume, that kind of sounds like you're running with a debugger
attached... see somewhere in the middle of this long thread, it is
known that the system will leak memory when you run with a debugger
attached - mostly when exceptions are involved, and
BitmapFactory.decodeFile() always throws (and catches) an exception.
Do you get the same results when you run without a debugger? All my
memory woes have been fixed when I stopped using a debugger except
when necessary.
-Mike
On Jan 31, 8:14 am, Guillaume Perrot <guillaume.p...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
