Bug 45271 - Memory leak when pushing a vc and returning
Summary: Memory leak when pushing a vc and returning
Status: RESOLVED ANSWERED
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 10.0 (iOS10)
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-10-11 10:19 UTC by Adam Hartley [MSFT]
Modified: 2016-10-12 12:16 UTC (History)
6 users (show)

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

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:
Status:
RESOLVED ANSWERED

Description Adam Hartley [MSFT] 2016-10-11 10:19:11 UTC
## Steps to reproduce

1. Download and run sample (in next private comment) on a device (Tested on iPhone 7 Plus 10.1 b3)
2. Profile the app with Instruments
3. Tap "Show View" then "Back"
4. Repeat and observe memory usage increase

## Expected result

No memory leak

## Actual result

Memory leak

## Notes

Tested in the simulator, but was not able to reproduce - only able to reproduce on a device

Included in sample is an Xcode project with the same behaviour, but no leak.

=== Xamarin Studio Enterprise ===

Version 6.1.1 (build 15)
Installation UUID: ad66a985-3d32-4bb5-935b-a2e10c4f0de0
Runtime:
	Mono 4.6.1 (mono-4.6.0-branch-c8sr0/ef43c15) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 406010005

=== NuGet ===

Version: 3.4.3.0

=== Xamarin.Profiler ===

Not Installed

=== Xamarin.Android ===

Version: 7.0.1.3 (Visual Studio Enterprise)
Android SDK: /Users/Adam/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		5.0 (API level 21)
		5.1 (API level 22)
		6.0 (API level 23)
		7.0 (API level 24)

SDK Tools Version: 25.2.2
SDK Platform Tools Version: 24.0.3
SDK Build Tools Version: 24.0.1

Java SDK: /usr
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Xamarin Android Player ===

Not Installed

=== Apple Developer Tools ===

Xcode 8.0 (11246)
Build 8A218a

=== Xamarin.Mac ===

Version: 2.10.0.105 (Visual Studio Enterprise)

=== Xamarin.iOS ===

Version: 10.0.1.10 (Visual Studio Enterprise)
Hash: ad1cd42
Branch: cycle8-sr0-xi
Build date: 2016-10-03 15:18:44-0400

=== Build Information ===

Release ID: 601010015
Git revision: fa52f02641726146e2589ed86ec4097fbe101888
Build date: 2016-09-22 08:03:02-04
Xamarin addins: 75d65712af93d54dc39ae4c42b21dfa574859fd6
Build lane: monodevelop-lion-cycle8-sr0

=== Operating System ===

Mac OS X 10.12.0
Darwin Adams-Retina-MacBook-Pro.local 16.0.0 Darwin Kernel Version 16.0.0
    Mon Aug 29 17:56:20 PDT 2016
    root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
Comment 2 Sebastien Pouliot 2016-10-11 15:27:48 UTC
An increase of memory is normal and does not imply a leak. In this case you just do not control the lifetime of the instances, nor do you control when the GC is executed. IOW the memory will be freed when the GC eventually  runs. 

On the simulator we run the GC every two seconds so people can notice issues with unreferenced instances (another kind of bugs). This is why you do not see such condition on the simulator (it exists but it's too short to detect).
Comment 3 Shirley Gong 2016-10-11 17:22:30 UTC
Do you mean GC should be called explicitly? If so where is the best place in this case?

I did try in another sample project where I called GC.Collect() on Dispose of the PageRenderer. However, I still be able to crash the app after push/pop the controller a number of times. (It does delay crash for quite a bit of time tho comparing to not calling GC). Please advice. Thanks.
Comment 4 Sebastien Pouliot 2016-10-11 17:34:25 UTC
> Do you mean GC should be called explicitly?

No, let the GC do it's job. It's very uncommon to require "hinting" the GC to run in production code (but it can be helpful when debugging as it helps having a more reproducible state).

> However, I still be able to crash the app after push/pop the controller a number of times.

It's likely unrelated to memory growth you were seeing on device (and not on the simulator) but it might be easier to duplicate under lower memory condition.

Please attach a symbolicated crash report and we'll have a better idea about what's going on.
Comment 5 Shirley Gong 2016-10-12 00:51:23 UTC
>It's likely unrelated to memory growth you were seeing on device (and not on the simulator)

I'm not too sure what this means? I was able to reproduce on simulator consistently. Please see: http://www.pdftron.com/ID-zJWLuhTffd3c/xamarin/xamarin_memory_leak.mov
Comment 6 Sebastien Pouliot 2016-10-12 12:16:47 UTC
From original description:

> Tested in the simulator, but was not able to reproduce - only able to reproduce on a device

Since support filed the issue it's possible that your configuration (and results) might be different. Please copy/paste your version information into the bug report (and with the symbolicated crash report).