Bug 30678 - Replacing a bound ObservableCollection entirely causes memory to leak
Summary: Replacing a bound ObservableCollection entirely causes memory to leak
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.4.4
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Eric Maupin
Depends on:
Reported: 2015-06-02 12:23 UTC by Rob DeRosa
Modified: 2016-04-09 01:16 UTC (History)
9 users (show)

Tags: AC
Is this bug a regression?: ---
Last known good build:

sample project (635.53 KB, application/zip)
2015-06-02 12:23 UTC, Rob DeRosa
screenshot (1.12 MB, image/png)
2015-06-02 12:24 UTC, Rob DeRosa

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Rob DeRosa 2015-06-02 12:23:36 UTC
Created attachment 11432 [details]
sample project

Attached is a sample that exhibits this behavior. There are 3 buttons (Odd, Even, All) that replace the filtered contents with a new list. Run through these 3 buttons about 20 times and you'll see the memory start to leak.
Comment 1 Rob DeRosa 2015-06-02 12:24:31 UTC
Created attachment 11433 [details]

Appears to have to do with PropertyChangedEvent handlers
Comment 2 Rob DeRosa 2015-06-02 12:37:51 UTC
Heapshot analysis output
Comment 3 Rajneesh Kumar 2015-06-04 08:58:08 UTC
I have checked this issue and here are my observation. As per instruction provided in bug description, 0after running the attached sample and run through these 3 buttons more than 20 times. I got the lines in application output like:
2015-06-04 18:17:24.139 ExcessiveCollectingTestiOS[2575:76898] UpdateCollectionInfo(): collection count=38, memory in use=15,006,992
UpdateCollectionInfo(): collection count=38, memory in use=15,006,992

Screencast: http://www.screencast.com/t/lCtEPnrYgJij

Could you please confirm me that Is this  the  same behaviour you are facing at your end ? If no then please suggest me that what steps should I follow to reproduce this issue. That would be very helpful to reproduce this issue at our end.


Application Output: https://gist.github.com/Rajneesh360Logica/9df34efe2711f06ae78c
Ide Logs: https://gist.github.com/Rajneesh360Logica/e4ac103d250e4701470c
Simulator Logs: https://gist.github.com/Rajneesh360Logica/7a1544d9042b23c74258
Build Output: https://gist.github.com/Rajneesh360Logica/33b7ef51558da55721f7

Environment Info:

Xamarin.Forms Version:

=== Xamarin Studio ===

Version 5.9.2 (build 4)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
	Mono 4.0.1 ((detached/ed1d3ec)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400010044

=== Apple Developer Tools ===

Xcode 6.2 (6776)
Build 6C131e

=== Xamarin.Mac ===

Version: (Business Edition)

=== Xamarin.Android ===

Version: (Business Edition)
Android SDK: /Users/MM/Desktop/android-sdk-macosx
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
Java SDK: /usr
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

=== Xamarin Android Player ===

Version: Unknown version
Location: /Applications/Xamarin Android Player.app

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 8a1cf8a
Branch: master
Build date: 2015-05-26 22:17:27-0400

=== Build Information ===

Release ID: 509020004
Git revision: 288eb01e990f2d93b856c9600a0c40708b930128
Build date: 2015-06-01 14:29:52-04
Xamarin addins: c12ed369b0e05dc5c35c9350fdcbc00a46c0ff99

=== Operating System ===

Mac OS X 10.9.5
Darwin MacMini.local 13.4.0 Darwin Kernel Version 13.4.0
    Sun Aug 17 19:50:11 PDT 2014
    root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
Comment 4 Rob DeRosa 2015-06-04 12:55:55 UTC
Ignore the output from the GC API - use Mono heapshot tool to look for allocations/references that should have been cleaned up.
Comment 5 Eric Maupin 2015-06-07 14:14:04 UTC
I am moving this to IN_PROGRESS because I've already looked into this and started working on it.
Comment 7 Anonymous 2016-03-24 14:18:20 UTC
We're coming up on 10 months since this was reported as being in progress. Can we get an update on this please?
Comment 8 Jason Smith [MSFT] 2016-04-09 01:16:46 UTC
Sorry this should have been resolved months ago, this work was completed and merged but we forgot to update the bug. If you are still having issues please re-open.