Bug 12281 - Is Memory Profiler showing the correct number of Instances ? Or something else wrong ?
Summary: Is Memory Profiler showing the correct number of Instances ? Or something els...
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 6.2.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Future Cycle (TBD)
Assignee: Rolf Bjarne Kvinge [MSFT]
Depends on:
Reported: 2013-05-17 07:26 UTC by David Lilley
Modified: 2016-05-24 19:24 UTC (History)
6 users (show)

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:

Description David Lilley 2013-05-17 07:26:27 UTC
We cannot seem to be able to get rid of these instances shown in the Memory Profiler. We are unsure if the profiler is not  showing the correct number of instances or there is something else preventing Garbage Collection.

Demos on Git

Xamarin Studio
Version 4.0.8 (build 2)
Installation UUID: 65a73d0d-2238-4cdc-85a1-0e8f1ff7362a
	Mono 2.10.12 (mono-2-10/c9b270d)
	GTK 2.24.16
	GTK# (
	Package version: 210120000

Not Installed

Apple Developer Tools
Xcode 4.6.2 (2067.2)
Build 4H1003

Version: (Enterprise Edition)
Hash: 8d98f5e
Build date: 2013-10-04 14:08:06-0400

Xamarin.Mac: Not Installed

Build Information
Release ID: 400080002
Git revision: 0a09117dec1aed78c735ac46f7a50ae7d12f7a7a
Build date: 2013-05-16 19:36:29+0000
Xamarin addins: 78d0437c3f92ae13042f81e5fd9487e2c28d5fbc

Operating System
Mac OS X 10.8.3
Darwin David-Lilley-Locals-iMac.local 12.3.0 Darwin Kernel Version 12.3.0
    Sun Jan  6 22:37:10 PST 2013
    root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64
Comment 1 Rolf Bjarne Kvinge [MSFT] 2013-05-22 08:16:33 UTC
Are you referring to this issue?

Comment 2 René Ruppert 2013-05-22 10:15:32 UTC
No. Different issue.

In this demo, presenting an instance of a UINavigationController modally refuses to release the instances of PSPDFViewController.

If instead an instance of PSPDFViewController is pushed onto an existing UINavigationController, everything works as expected.

I really doubt that PSPDFKit is leaking because the same demo run in ObjC does not show these issues.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2013-05-22 16:36:56 UTC
Exactly what do I have to do to reproduce this issue then?
Comment 4 René Ruppert 2013-05-22 17:23:51 UTC
Hi Rolf,

I'm terribly sorry for bugging you about this over and over. It's just so hard to get answers and it's hard to pin if there are problems in PSPDFKit, in MonoTouch, in the bindings, in what we're doing or in a combination of things. I tried to keep the demo project really simple.

wrt your question: The one mentioned in the bug here? Download the linked project and run it. The code contains comments about what is expected to happen and what does happen.

I have also created a video that demonstrates what I get here, so we're talking about the same things: http://screencast.com/t/CI6a9McIoVh

The first example presents a UINavigationController modally and the only controller on the stack is a PSPDFViewController.
 Do this 5 times and watch console output. After the fifth time, PSPDFKit will complain that there are 5 instances of PSPDFViewController around and we cannot get rid of these. To our understanding, there is no root object that would hold a reference.
In the thread on the forums, you argue that this might be a problem of PSPDFKit. However, this problem does not occur in the native version of the demo.

The 2nd example works as expected: an instance of PSPDFViewController is pushed onto an existing UINavigationController. Do this 3 times and run Mono Profiler in parallel. Take a snapshot after the third time. The profiler will show one instance of PSPDFViewController. Expected bahevior, although I think there should be 0 instances, but that's nitpicking.

The 3rd example does exactly the same as the 2nd example with one little difference: it uses a subclass of PSPDFViewController. This subclass adds exactly zero additional functionality, it only writes to the console if it is getting finalized/disposed. However now, if you do that 3 times you will see 3 instances of the subclass of PSPDFViewController in the Profiler.

What do I want to demonstrate here?
* What holds a reference to PSPDFViewController in example 1? And why only if modal presentation is used ? I assume a bug here in MonoTouch. Running the same demo in the native ObjC version does not show this issue, so I doubt it is a problem of PSPDFKit. It could still be something with the bindings. But what?

* Is example 2 OK? Should the number of instances not be 0?

* I want to understand if the Mono Profiler is showing correct or wrong information. Case 3 indicates something is wrong. Especially as case 3 is the same as case 2, just a managed subclass of a native controller is used.

I run all these examples in the iOS 6.1 Simulator with MonoTouch

If you tell me that you do NOT get the output of PSPDFKit that there are 5 living instances of PSPDFKit, something must be different in your installation. We can see it here on two different machines.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2013-05-22 19:08:36 UTC
The first example is a bug in MonoTouch. It's a variation of bug #1889 - internally we keep a stack of modal view controllers, pushing and popping when PresentViewController and DismissViewController are called. The problem relies in the Close button that's shown - when that button is tapped (by the user, not programmatically) we're not notified that the modal view controller has exited, and the stack of modal view controllers is not updated. I'll investigate this to see if I can come up with a solution.

I do get the 5 instance warning with this sample.

The second example is bug #1889. That bug also contains a workaround (though I would recommend against it unless you really need the memory right away - it's technically not a leak, it's just getting freed a bit later).

I can't reproduce the HeapShot results you get with the third example, in my case there is only one instance of KSKioskViewController no matter what I do. I do find it quite strange though (I've never seen the profiler being wrong before, yet your evidence seems to prove it). Can you screenshot exactly what you do with HeapShot to get this behavior?
Comment 6 Rolf Bjarne Kvinge [MSFT] 2013-05-22 19:09:08 UTC
Info provided.
Comment 7 Rolf Bjarne Kvinge [MSFT] 2013-05-22 19:17:20 UTC
BTW thanks a lot for the simple demo, it makes it a lot easier to track down. And I do completely understand how complicated it can be to find out exactly what's going on.
Comment 8 René Ruppert 2013-05-23 04:47:47 UTC
I have captured another video for you: http://screencast.com/t/6f0LL7yCxP6n

This one shows what I do in order to get more and more KSKioskViewController instances.
After the third time I fire a memory warning but the instances don't get freed.
If I expand the KSKioskViewController instance in the profiler, I cannot see any references from it. If I invert the view, I cannot see anything referencing it.
Comment 10 PJ 2013-11-19 16:44:38 UTC
This bug was targeted for a past milestone, moving to the next non-hotfix active milestone.
Comment 11 Rolf Bjarne Kvinge [MSFT] 2015-04-21 06:27:44 UTC
@Rene, the test case seems to be gone (I get a 404 here: https://github.com/Krumelur/XamarinBindings), do you still have it around?
Comment 12 GouriKumari 2016-01-11 21:30:29 UTC
Based on comment #11, I am moving this bug to far future.
Comment 13 Sebastien Pouliot 2016-05-24 19:24:39 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!