Incoming references and path to GC root show only the TmpTestActivity.
On Mar 30, 5:56 pm, Mark Murphy mmur...@commonsware.com wrote:
On Wed, Mar 30, 2011 at 7:45 PM, ivan istas...@gmail.com wrote:
I just ran the ApiDemos app (from SDK 7) in a stand alone emulator.
I went to List1, then
On Thu, Mar 31, 2011 at 11:58 AM, ivan istas...@gmail.com wrote:
Incoming references and path to GC root show only the TmpTestActivity.
If I am understanding you correctly, then, it is merely a matter of
them not having been GC'd yet. Bear in mind that the Dalvik GC
implementation does not try
So to reiterate ...
I can see every instance of a ListView/ListActivity (ever created)
sitting around in memory, even though I force a GC in every call to
onDestroy().
... And this is the expected behavior, because the Dalvik GC will
eventually collect them.
Why isn't this the case with other
Ok I just tested the api demo again.
I went in and out of List1.java 15 times, and only saw 8 instances
still on the heap.
So, clearly some are being GC'd.
My question still remains... Why doesn't this happen with other views?
On Mar 31, 11:50 am, ivan istas...@gmail.com wrote:
So to
I have played with this MANY times. The only solution I have seen is to
walkthetree in the listview and recycle your objects by hand
On Thu, Mar 31, 2011 at 2:08 PM, ivan istas...@gmail.com wrote:
Ok I just tested the api demo again.
I went in and out of List1.java 15 times, and only saw 8
Sorry I didn't explain myself fully. In our layout we have a listview with
rather large images. We have shown many times that the gc does not run
quick enough to clean up the images onDestroy, onConfigurationChange, etc
and are getting OOM exceptions. We have seen bitmaps getting stranded and
There is no need to do this whatsoever. And you cannot recycle Views
anyway, at most you can set all the references to null manually which will
not make much of a difference. The GC will eventually collect the ListView
instances.
On Thu, Mar 31, 2011 at 11:32 AM, Matthew Powers mtpow...@gmail.com
Bitmaps are an entirely different problem. Android 3.0 improves bitmaps
memory management a lot by reducing the time it takes for them to be
reclaimed by the GC. A leak happens only if there's memory that never gets
reclaimed, which I believe is not the case here. I would again be happy to
track
Yeah we have a unique setup. An e-reader that uses a listview to actually
scroll vertically instead of using the conventional gallery, with very high
resolution images. It doesn't surprise me that you have not seen this
before, its an unconventional way of using a listview and we are using very
I have seen many lists with images before. Again, I'd be happy to fix a
possible issue but I would need a repro case and an explanation of what is
holding memory and how. I can certainly see views moved to the scrap heap
holding onto these large images, but the scrap heap is mostly filled when a
Roman, can you recommend your preferred way for analyzing whether or
not an object is being withheld from GC by another?
On Mar 31, 2:05 pm, Romain Guy romain...@android.com wrote:
I have seen many lists with images before. Again, I'd be happy to fix a
possible issue but I would need a repro
Ivan,
Which Android version are testing this with?
Among the devices I own, 2.2 seems much more aggressive with GC than 2.1.
01.04.2011 0:20 пользователь ivan istas...@gmail.com написал:
Roman, can you recommend your preferred way for analyzing whether or
not an object is being withheld from
If I am understanding you correctly, then, it is merely a matter of
them not having been GC'd yet. Bear in mind that the Dalvik GC
implementation does not try to reclaim all unreferenced objects in a
single pass.
So how useful HPROF is? If it's impossible to tell if an object is
sitting
So how useful HPROF is? If it's impossible to tell if an object is
sitting there because the VM hadn't gotten around collecting it yet or
because it's being leaked, I'd say it's not very useful.
It is useful, just look at the GC roots of an object to know whether it will
be collected or
Mark,
I accidentally posted this before I was done... please see my second
post with the same title and II appended.
Sorry about the confusion.
On Mar 30, 11:10 am, Mark Murphy mmur...@commonsware.com wrote:
On Wed, Mar 30, 2011 at 1:06 PM, ivan istas...@gmail.com wrote:
I have read copious
onDestory has been called every time, which I've tested with a break
point .
On Mar 30, 11:23 am, Mark Murphy mmur...@commonsware.com wrote:
On Wed, Mar 30, 2011 at 1:18 PM, ivan istas...@gmail.com wrote:
I accidentally posted that last one before I was done.
I have read copious posts on
Are you running the app in the debugger?
30.03.2011 21:28, ivan пишет:
onDestory has been called every time, which I've tested with a break
point .
On Mar 30, 11:23 am, Mark Murphymmur...@commonsware.com wrote:
On Wed, Mar 30, 2011 at 1:18 PM, ivanistas...@gmail.com wrote:
I accidentally
In addition, I've read that the leak doesn't occur while the app is
running in a non-debug session. This is not the case with my
experiments. I see the leak regardless.
On Mar 30, 11:28 am, ivan istas...@gmail.com wrote:
onDestory has been called every time, which I've tested with a break
Also, I'm using Android SDK build 8 (2.2).
On Mar 30, 11:37 am, ivan istas...@gmail.com wrote:
In addition, I've read that the leak doesn't occur while the app is
running in a non-debug session. This is not the case with my
experiments. I see the leak regardless.
On Mar 30, 11:28 am, ivan
Kostya asked if you were running under the debugger. This is relevant
because previously I too had a memory leak involved with ListViews and
eventually discovered that it only happened if I was running under the
debugger. So if you are running under the debugger, you might check
it without the
John, I've read your post about this ... I launched a non-debug
version through eclipse (i.e. ctrl + F11) and pulled a heap hprof file
showing the same memory leaks.
Am I missing a step? When I was running I could see the process in
DDMS, but break points and stack info were not available -- so
On Wed, Mar 30, 2011 at 3:28 PM, ivan istas...@gmail.com wrote:
John, I've read your post about this ... I launched a non-debug
version through eclipse (i.e. ctrl + F11) and pulled a heap hprof file
showing the same memory leaks.
Am I missing a step? When I was running I could see the
I'm using a deice.
On Mar 30, 1:30 pm, Mark Murphy mmur...@commonsware.com wrote:
On Wed, Mar 30, 2011 at 3:28 PM, ivan istas...@gmail.com wrote:
John, I've read your post about this ... I launched a non-debug
version through eclipse (i.e. ctrl + F11) and pulled a heap hprof file
showing
On Wed, Mar 30, 2011 at 5:14 PM, ivan istas...@gmail.com wrote:
I'm using a deice.
You should be testing this on an emulator in addition to your device.
Your device may have its own set of bugs and (strangely enough) the
home screen can impact this sort of thing as well. For a problem like
this,
What exactly is leaking? What is the chain of references causing the leak?
If what you are describing is true it would affect pretty much every Android
application, which seems unlikely.
On Wed, Mar 30, 2011 at 2:23 PM, Mark Murphy mmur...@commonsware.comwrote:
On Wed, Mar 30, 2011 at 5:14 PM,
When I use MAT to look at TmpTestActivity, I
1.) Open the OQL tab in MAT and type the following query select *
from com.package name.TmpTestActivity and run the query
2.) I right click on one of the TmpTestActivity result rows and choose
List Objecst - with incoming references ... the
I just ran the ApiDemos app (from SDK 7) in a stand alone emulator.
I went to List1, then back, then to List2, then back, then back to
List1, etc... then:
1.) I used adb shell ps to view the process id.
2.) I used adb kill -10 pid to kill the process and dump an hprof
3.) I pulled the hprof from
On Wed, Mar 30, 2011 at 7:45 PM, ivan istas...@gmail.com wrote:
I just ran the ApiDemos app (from SDK 7) in a stand alone emulator.
I went to List1, then back, then to List2, then back, then back to
List1, etc... then:
1.) I used adb shell ps to view the process id.
2.) I used adb kill -10
28 matches
Mail list logo
