Note: I've created a simple project—you can see how switching types between
UIButton
andCustomButton
in storyboard changes GC behavior.
I'm trying to get my head wrapped around MonoTouch garbage collector.
The issue is similar to the one fixed in MT 4.0, however with inherited types.
To illustrate it, consider two view controllers, parent and child.
Child's view contains a single UIButton
that writes to console on tap.
Controller's Dispose
method throws an exception so it's hard to miss.
Here goes child view controller:
public override void ViewDidLoad () { base.ViewDidLoad (); sayHiButton.TouchUpInside += (sender, e) => SayHi(); } } void SayHi() { Console.WriteLine("Hi"); } protected override void Dispose (bool disposing) { throw new Exception("Hey! I've just been collected."); base.Dispose (disposing); }
Parent view controller just presents child controller and sets a timer to dismiss it and run GC:
public override void ViewDidLoad () { base.ViewDidLoad (); var child = (ChildViewController)Storyboard.InstantiateViewController("ChildViewController"); NSTimer.CreateScheduledTimer(2, () => { DismissViewController(false, null); GC.Collect(); }); PresentViewController(child, false, null); }
If you run this code, it predictably crashes inside ChildViewController.Dispose()
called from its finalizer because child controller has been garbage collected. Cool.
Now open the storyboard and change button type to CustomButton
. MonoDevelop will generate a simple UIButton
subclass:
[Register ("CustomButton")] public partial class CustomButton : UIButton { public CoolButton (IntPtr handle) : base (handle) { } void ReleaseDesignerOutlets() { } }
Somehow changing the button type to CustomButton
is enough to trick garbage collector into thinking child controller is not yet eligible for collection.
How is that so?
This is an unfortunate side-effect of MonoTouch (who is garbage collected) having to live in a reference counted world (ObjectiveC).
There are a few pieces of information required to be able to understand what's going on:
What happens in your case is a cycle, which crosses the MonoTouch/ObjectiveC bridge and due to the above rules, the GC can't determine that the cycle can be collected.
This is what happens:
Now you see that the CustomButton instance will not be freed, because its reference count is 2. And the ChildViewController instance will not be freed because the CustomButton's event handler has a reference to it.
There are a couple of ways to break the cycle to fix this:
[1] This is because a managed object may contain user state. For managed objects which are mirroring a corresponding native object (such as the managed UIView instance) MonoTouch knows that the instance can not contain any state, so as soon as no managed code has a reference to the managed instance, the GC can collect it. If a managed instance is required at a later stage, we just create a new one.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With