Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Created attachment 4277 [details]
Test case project
When an UIView is created by a designer-generated UIViewController and used as a child view like this:
ViewController2 child = new ViewController2();
It looks like no reference to 'child' is stored, which results in a segmentation fault when the child view calls an event handler on its ViewController.
Explicitly storing a reference to the ViewController instance prevents the crash, as shown in the test case project, in file ViewController1.cs. So far I have only seen this crash happening in the iOS simulator.
The stack trace is included in the test case project archive, named Stacktrace.txt.
Created attachment 4278 [details]
The C# code above does not maintain a managed reference to `child`. That means that the GC is free to collect the managed instance at anytime.
However the native peer to the controller still exists (not an issue in itself) and could try to call back (e.g. events) into managed code (that's an issue since it was collected). To avoid this you need to keep a reference (e.g. a field) to the UIViewController as long as you're using its View.
Here's a good video on the subject from the Evolve conference: http://xamarin.com/evolve/2013#session-0w86u7bco2
> So far I have only seen this crash happening in the iOS simulator.
That's normal. The GC is configured to collect very frequently on the simulator (that's sometime referred, by some people, as being "aggressive"). This is by design since:
(a) there's a lot of CPU available on your Mac;
(b) it make it easier (and faster) to find such mistakes (that could be very difficult to reproduce otherwise). IOW it will happen on device but it's easy to miss (while testing) and you do not want your customers to find those before you do.