No I was not using a debugger, just DDMS.
2009/2/1 EboMike <ebom...@gmail.com>
>
> 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.
> >
> >
> >
>
--
Guillaume Perrot
Software Engineer at Ubikod
BuddyMob developer
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
