subject:"\[android\-developers\] Re\: ListView leaks memory II"

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 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 the virtual device's sdcard to my machine
  4.) I converted the hprof with hprof-conv
  5.) I opened the hprof with MAT in eclipse
  6.) I opened OQL tab and ran select * from
  com.example.android.apis.view.List1
  7.) I see multiple instances of com.example.android.apis.view.List1
  lingering in memory

 You forgot:

 8.) Made note of what is holding onto those instances

 If they are not referenced by anything, they are simply garbage that
 has not been collected. Conversely, if they are referenced by
 something, it is important to know what that something is.

 --
 Mark Murphy (a Commons 
 Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

 _The Busy Coder's Guide to *Advanced* Android Development_ Version
 1.9.2 Available!

-- 
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

Re: [android-developers] Re: ListView leaks memory II

2011-03-31 Thread Mark Murphy

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 to reclaim all unreferenced objects in a
single pass.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

Android Training in NYC: http://marakana.com/training/android/

-- 
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

[android-developers] Re: ListView leaks memory II

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 views?



On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:
 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 to reclaim all unreferenced objects in a
 single pass.

 --
 Mark Murphy (a Commons 
 Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

 Android Training in NYC:http://marakana.com/training/android/

-- 
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

[android-developers] Re: ListView leaks memory II

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 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 views?

On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:

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 to reclaim all unreferenced objects in a
single pass.

--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

Android Training in NYC:http://marakana.com/training/android/

--
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

Re: [android-developers] Re: ListView leaks memory II

2011-03-31 Thread Matthew Powers

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 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 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 views?
 
  On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:
 
   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 to reclaim all unreferenced objects in a
   single pass.
 
   --
   Mark Murphy (a Commons Guy)http://commonsware.com|
 http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
 
   Android Training in NYC:http://marakana.com/training/android/

 --
 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

-- 
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

Re: [android-developers] Re: ListView leaks memory II

2011-03-31 Thread Matthew Powers

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
have had to clean them up by hand, thus walking the tree and recycling the
individual bitmaps by hand (nulling out does nothing). There appears to be
new documentation about the recycler where theoretcially we could set a
recycler listener and monitor when a view is moved onto the scrap heap to
achieve the same thing, however I have seen instances of onMovedToScrapHeap
firing on views that are still in focus.  I have submitted a bug with
detailed instructions on how to reproduce this.
I could be wrong but we have had a lot of engineers looking at this leak in
the listview over the last several months.

On Thu, Mar 31, 2011 at 2:40 PM, Romain Guy romain...@android.com wrote:

 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.comwrote:

 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 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 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 views?
 
  On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:
 
   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 to reclaim all unreferenced objects in a
   single pass.
 
   --
   Mark Murphy (a Commons Guy)http://commonsware.com|
 http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
 
   Android Training in NYC:http://marakana.com/training/android/

 --
 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


  --
 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




 --
 Romain Guy
 Android framework engineer
 romain...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support.  All such questions should be posted on public
 forums, where I and others can see and answer them


-- 
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

Re: [android-developers] Re: ListView leaks memory II

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 wrote:

 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 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 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 views?
 
  On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:
 
   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 to reclaim all unreferenced objects in a
   single pass.
 
   --
   Mark Murphy (a Commons Guy)http://commonsware.com|
 http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
 
   Android Training in NYC:http://marakana.com/training/android/

 --
 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


  --
 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




-- 
Romain Guy
Android framework engineer
romain...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support.  All such questions should be posted on public
forums, where I and others can see and answer them

-- 
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

Re: [android-developers] Re: ListView leaks memory II

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 down and fix such an issue but the fact that we've never witnessed it
in many many apps that use ListView makes me doubtful.

On Thu, Mar 31, 2011 at 11:47 AM, Matthew Powers mtpow...@gmail.com wrote:

 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
 have had to clean them up by hand, thus walking the tree and recycling the
 individual bitmaps by hand (nulling out does nothing). There appears to be
 new documentation about the recycler where theoretcially we could set a
 recycler listener and monitor when a view is moved onto the scrap heap to
 achieve the same thing, however I have seen instances of onMovedToScrapHeap
 firing on views that are still in focus.  I have submitted a bug with
 detailed instructions on how to reproduce this.
 I could be wrong but we have had a lot of engineers looking at this leak in
 the listview over the last several months.


 On Thu, Mar 31, 2011 at 2:40 PM, Romain Guy romain...@android.com wrote:

 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.comwrote:

 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 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 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 views?
 
  On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:
 
   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 to reclaim all unreferenced objects in a
   single pass.
 
   --
   Mark Murphy (a Commons Guy)http://commonsware.com|
 http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
 
   Android Training in NYC:http://marakana.com/training/android/

 --
 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


  --
 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




 --
 Romain Guy
 Android framework engineer
 romain...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support.  All such questions should be posted on public
 forums, where I and others can see and answer them





-- 
Romain Guy
Android framework engineer
romain...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support.  All such questions should be posted on public
forums, where I and others can see and answer them

-- 
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

Re: [android-developers] Re: ListView leaks memory II

2011-03-31 Thread Matthew Powers

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
high res images.  I can assure you though, it happens.


On Thu, Mar 31, 2011 at 2:51 PM, Romain Guy romain...@android.com wrote:

 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 down and fix such an issue but the fact that we've never witnessed it
 in many many apps that use ListView makes me doubtful.

 On Thu, Mar 31, 2011 at 11:47 AM, Matthew Powers mtpow...@gmail.comwrote:

 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
 have had to clean them up by hand, thus walking the tree and recycling the
 individual bitmaps by hand (nulling out does nothing). There appears to be
 new documentation about the recycler where theoretcially we could set a
 recycler listener and monitor when a view is moved onto the scrap heap to
 achieve the same thing, however I have seen instances of onMovedToScrapHeap
 firing on views that are still in focus.  I have submitted a bug with
 detailed instructions on how to reproduce this.
 I could be wrong but we have had a lot of engineers looking at this leak
 in the listview over the last several months.


 On Thu, Mar 31, 2011 at 2:40 PM, Romain Guy romain...@android.comwrote:

 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.comwrote:

 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 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 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 views?
 
  On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:
 
   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 to reclaim all unreferenced objects in
 a
   single pass.
 
   --
   Mark Murphy (a Commons Guy)http://commonsware.com|
 http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
 
   Android Training in NYC:http://marakana.com/training/android/

 --
 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


  --
 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




 --
 Romain Guy
 Android framework engineer
 romain...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support.  All such questions should be posted on public
 forums, where I and others can see and answer them





 --
 Romain Guy
 Android framework engineer
 romain...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support.  All such questions should be posted on public
 forums, where I and others can see and answer

Re: [android-developers] Re: ListView leaks memory II

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
list uses views of different types, which doesn't seem to be what you are
describing (I would expect at most one view in the scrap heap in your case.)

On Thu, Mar 31, 2011 at 12:02 PM, Matthew Powers mtpow...@gmail.com wrote:

 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
 high res images.  I can assure you though, it happens.


 On Thu, Mar 31, 2011 at 2:51 PM, Romain Guy romain...@android.com wrote:

 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 down and fix such an issue but the fact that we've never witnessed it
 in many many apps that use ListView makes me doubtful.

 On Thu, Mar 31, 2011 at 11:47 AM, Matthew Powers mtpow...@gmail.comwrote:

 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
 have had to clean them up by hand, thus walking the tree and recycling the
 individual bitmaps by hand (nulling out does nothing). There appears to be
 new documentation about the recycler where theoretcially we could set a
 recycler listener and monitor when a view is moved onto the scrap heap to
 achieve the same thing, however I have seen instances of onMovedToScrapHeap
 firing on views that are still in focus.  I have submitted a bug with
 detailed instructions on how to reproduce this.
 I could be wrong but we have had a lot of engineers looking at this leak
 in the listview over the last several months.


 On Thu, Mar 31, 2011 at 2:40 PM, Romain Guy romain...@android.comwrote:

 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.comwrote:

 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 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 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 views?
 
  On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:
 
   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 to reclaim all unreferenced objects in
 a
   single pass.
 
   --
   Mark Murphy (a Commons Guy)http://commonsware.com|
 http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy
 
   Android Training in NYC:http://marakana.com/training/android/

 --
 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


  --
 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




 --

[android-developers] Re: ListView leaks memory II

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 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
 list uses views of different types, which doesn't seem to be what you are
 describing (I would expect at most one view in the scrap heap in your case.)



 On Thu, Mar 31, 2011 at 12:02 PM, Matthew Powers mtpow...@gmail.com wrote:
  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
  high res images.  I can assure you though, it happens.

  On Thu, Mar 31, 2011 at 2:51 PM, Romain Guy romain...@android.com wrote:

  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 down and fix such an issue but the fact that we've never witnessed it
  in many many apps that use ListView makes me doubtful.

  On Thu, Mar 31, 2011 at 11:47 AM, Matthew Powers mtpow...@gmail.comwrote:

  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
  have had to clean them up by hand, thus walking the tree and recycling the
  individual bitmaps by hand (nulling out does nothing). There appears to be
  new documentation about the recycler where theoretcially we could set a
  recycler listener and monitor when a view is moved onto the scrap heap to
  achieve the same thing, however I have seen instances of 
  onMovedToScrapHeap
  firing on views that are still in focus.  I have submitted a bug with
  detailed instructions on how to reproduce this.
  I could be wrong but we have had a lot of engineers looking at this leak
  in the listview over the last several months.

  On Thu, Mar 31, 2011 at 2:40 PM, Romain Guy romain...@android.comwrote:

  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.comwrote:

  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 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 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 views?

   On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com wrote:

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 to reclaim all unreferenced objects in
  a
single pass.

--
Mark Murphy (a Commons Guy)http://commonsware.com|
 http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

Android Training in NYC:http://marakana.com/training/android/

  --
  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

   --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To

Re: [android-developers] Re: ListView leaks memory II

2011-03-31 Thread Kostya Vasilyev

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 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 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
 list uses views of different types, which doesn't seem to be what you are
 describing (I would expect at most one view in the scrap heap in your
case.)



 On Thu, Mar 31, 2011 at 12:02 PM, Matthew Powers mtpow...@gmail.com
wrote:
  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
  high res images.  I can assure you though, it happens.

  On Thu, Mar 31, 2011 at 2:51 PM, Romain Guy romain...@android.com
wrote:

  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 down and fix such an issue but the fact that we've never
witnessed it
  in many many apps that use ListView makes me doubtful.

  On Thu, Mar 31, 2011 at 11:47 AM, Matthew Powers mtpow...@gmail.com
wrote:

  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
  have had to clean them up by hand, thus walking the tree and
recycling the
  individual bitmaps by hand (nulling out does nothing). There appears
to be
  new documentation about the recycler where theoretcially we could set
a
  recycler listener and monitor when a view is moved onto the scrap
heap to
  achieve the same thing, however I have seen instances of
onMovedToScrapHeap
  firing on views that are still in focus.  I have submitted a bug with
  detailed instructions on how to reproduce this.
  I could be wrong but we have had a lot of engineers looking at this
leak
  in the listview over the last several months.

  On Thu, Mar 31, 2011 at 2:40 PM, Romain Guy romain...@android.com
wrote:

  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
wrote:

  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 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 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 views?

   On Mar 31, 10:28 am, Mark Murphy mmur...@commonsware.com
wrote:

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 to reclaim all unreferenced
objects in
  a
single pass.

--
Mark Murphy (a Commons Guy)http://commonsware.com|
 
http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

Android Training in NYC:http://marakana.com/training/android/

  --
  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

[android-developers] Re: ListView leaks memory II

2011-03-31 Thread Zsolt Vasvari

 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 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.

I've had this same issue once and then I stopped using HPROF
altogether because there was just so much to look at.

It really needs a RECLAIM ALL MEMORY NOW!!! button.

-- 
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

Re: [android-developers] Re: ListView leaks memory II


 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 not. We use hprof all the time on the Android team to track
down memory issues (leaks or not) and we find it extremely valuable. It
becomes even easier to use when you rely on a visualization tool like MAT.

-- 
Romain Guy
Android framework engineer
romain...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support.  All such questions should be posted on public
forums, where I and others can see and answer them

-- 
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

[android-developers] Re: ListView leaks memory II

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 this, but no solution. After using MAT
extensively on a simple ApiDemo list view sample, I am ABSOLUTELY
convinced that the ListView/ListActivity is leaking memory. I say
this because I can see every instance I've created persisting in
memory -- regardless of forcing a garbage collection. To repeat copy
the code below into a project, create another simple Activity and go
back and forth between the two a few times. Then in DDMS force a GC
and dump the heap hprof file. Open the OQL tab in MAT and type the
following query select * from com.package name.TmpTestActivity and
run... you'll notice multiple instances of TmpTestActivity in memory.

Has onDestroy() been called on the multiple instances of
TmpTestActivity in memory?

If not, they are not leaked. Android just hasn't kicked them out of
RAM yet. That is perfectly normal behavior.

--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!

Re: [android-developers] Re: ListView leaks memory II

2011-03-30 Thread Kostya Vasilyev

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 posted that last one before I was done.
I have read copious posts on this, but no solution. After using MAT
extensively on a simple ApiDemo list view sample, I am ABSOLUTELY
convinced that the ListView/ListActivity is leaking memory. I say
this because I can see every instance I've created persisting in
memory -- regardless of forcing a garbage collection. To repeat copy
the code below into a project, create another simple Activity and go
back and forth between the two a few times. Then in DDMS force a GC
and dump the heap hprof file. Open the OQL tab in MAT and type the
following query select * from com.package name.TmpTestActivity and
run... you'll notice multiple instances of TmpTestActivity in memory.

Has onDestroy() been called on the multiple instances of
TmpTestActivity in memory?

If not, they are not leaked. Android just hasn't kicked them out of
RAM yet. That is perfectly normal behavior.

--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!

--
Kostya Vasilyev -- http://kmansoft.wordpress.com

[android-developers] Re: ListView leaks memory II

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
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.

Has onDestroy() been called on the multiple instances of
TmpTestActivity in memory?

If not, they are not leaked. Android just hasn't kicked them out of
RAM yet. That is perfectly normal behavior.

--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!

[android-developers] Re: ListView leaks memory II

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 istas...@gmail.com wrote:

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.

Has onDestroy() been called on the multiple instances of
TmpTestActivity in memory?

If not, they are not leaked. Android just hasn't kicked them out of
RAM yet. That is perfectly normal behavior.

--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!

[android-developers] Re: ListView leaks memory II

2011-03-30 Thread John Gaby

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 debugger running to see if you still have a problem.

On Mar 30, 10:53 am, ivan istas...@gmail.com wrote:
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 istas...@gmail.com wrote:

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.

Has onDestroy() been called on the multiple instances of
TmpTestActivity in memory?

If not, they are not leaked. Android just hasn't kicked them out of
RAM yet. That is perfectly normal behavior.

--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!

[android-developers] Re: ListView leaks memory II

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 I
figured this was not running in the debugger.

On Mar 30, 12:34 pm, John Gaby jg...@gabysoft.com wrote:
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 debugger running to see if you still have a problem.

On Mar 30, 10:53 am, ivan istas...@gmail.com wrote:

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 istas...@gmail.com wrote:

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 this, but no solution. After using MAT
extensively on a simple ApiDemo list view sample, I am ABSOLUTELY
convinced that the ListView/ListActivity is leaking memory. I say
this because I can see every instance I've created persisting in
memory -- regardless of forcing a garbage collection. To repeat
copy
the code below into a project, create another simple Activity and go
back and forth between the two a few times. Then in DDMS force a GC
and dump the heap hprof file. Open the OQL tab in MAT and type the
following query select * from com.package name.TmpTestActivity
and
run... you'll notice multiple instances of TmpTestActivity in
memory.

Has onDestroy() been called on the multiple instances of
TmpTestActivity in memory?

If not, they are not leaked. Android just hasn't kicked them out of
RAM yet. That is perfectly normal behavior.

--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!

Re: [android-developers] Re: ListView leaks memory II

2011-03-30 Thread Mark Murphy

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 process in
 DDMS, but break points and stack info were not available -- so I
 figured this was not running in the debugger.

Run the emulator outside of Eclipse.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!

-- 
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

[android-developers] Re: ListView leaks memory II

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 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 I
  figured this was not running in the debugger.

 Run the emulator outside of Eclipse.

 --
 Mark Murphy (a Commons 
 Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

 _The Busy Coder's Guide to *Advanced* Android Development_ Version
 1.9.2 Available!

-- 
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

Re: [android-developers] Re: ListView leaks memory II

2011-03-30 Thread Mark Murphy

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, the emulator will be a truer test of what the unmodified Android
code will do. Use a standalone emulator and the standalone DDMS
(tools/ddms from your SDK installation) to ensure Eclipse is not the
one causing you difficulty.

On the plus side, I didn't realize you could dump the heap of a
process that's running on hardware, so that's good to know.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version
1.9.2 Available!

-- 
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

Re: [android-developers] Re: ListView leaks memory II

2011-03-30 Thread Romain Guy

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, 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, the emulator will be a truer test of what the unmodified Android
 code will do. Use a standalone emulator and the standalone DDMS
 (tools/ddms from your SDK installation) to ensure Eclipse is not the
 one causing you difficulty.

 On the plus side, I didn't realize you could dump the heap of a
 process that's running on hardware, so that's good to know.

 --
 Mark Murphy (a Commons Guy)
 http://commonsware.com | http://github.com/commonsguy
 http://commonsware.com/blog | http://twitter.com/commonsguy

 _The Busy Coder's Guide to *Advanced* Android Development_ Version
 1.9.2 Available!

 --
 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




-- 
Romain Guy
Android framework engineer
romain...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support.  All such questions should be posted on public
forums, where I and others can see and answer them

-- 
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

[android-developers] Re: ListView leaks memory II

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 results of which is
the same TmpTestActivity instance.
3.) I then right click on the result and choose Path to GC Roots -
Exclude all soft/weak/phantom references, which results in:

i.) a ListView referencing the context of TmpTestActivity
ii.) a FrameLayout referencing the context of TmpTestActivity
iii.) an android.app.ContextImpl referencing the outer context of
TmpTestActivity

Note, if I run this test with an activity that doesn't contain the
ListView I do not see extra activities sitting around in memory.



On Mar 30, 4:35 pm, Romain Guy romain...@android.com wrote:
 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, 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, the emulator will be a truer test of what the unmodified Android
  code will do. Use a standalone emulator and the standalone DDMS
  (tools/ddms from your SDK installation) to ensure Eclipse is not the
  one causing you difficulty.

  On the plus side, I didn't realize you could dump the heap of a
  process that's running on hardware, so that's good to know.

  --
  Mark Murphy (a Commons Guy)
 http://commonsware.com|http://github.com/commonsguy
 http://commonsware.com/blog|http://twitter.com/commonsguy

  _The Busy Coder's Guide to *Advanced* Android Development_ Version
  1.9.2 Available!

  --
  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

 --
 Romain Guy
 Android framework engineer
 romain...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support.  All such questions should be posted on public
 forums, where I and others can see and answer them

-- 
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

[android-developers] Re: ListView leaks memory II