I don't think I am doing anything "funky".
Basically I have a view composed of two pages, one which is visible
and one which is invisible at any given time. When the visible page is
clicked, the visible page becomes invisible and the invisible page is
made visible.
One page consists of a gallery. The other page is an ImageView. Each
time the ImageView is made visible it is updated with a call to:
ImageView.setImageBitmap(BitmapFactory.decodeFile
(currentGalleryPicture)). After about 20 iterations of this, there is
OOM error.
>From your helpful comments, I realize that my OOM error is occurring
without the debugger attached. This must relate then to the decodeFile
() problem more than the Gallery memory leak. I tried attaching the
debugger and attempted to get an OOM simply from using gallery, but I
was not able to get it to crash. Perhaps my gallery is too small
(20items, each ~20k).
I read in this post that I am supposed to have 16Mb available for my
computer, but when I check the "heap size" it is never > 2.8Mb, and
yet it still crashes. (The "allocated" is never >2Mb...) When you
wrote: "I noticed an immediate continual increase in memory usage ",
which memory are you referring to: "heap size" or "allocated"? I
don't see either of these change except when there is GC, which I can
identify by the log file, but that doesn't happen very often. I did
notice that if I go very slowly toggling my views, then the uncommon
GC that does occur is adequate to prevent an OOM error. However, the
GC certainly isn't doing its job.
Thanks for your comments, Mike, it improved my understanding of the
issues.
Jim
On Jan 17, 4:31 pm, 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.- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
