Bug 25980 - Thread access exception when using MFMailComposeViewController
Summary: Thread access exception when using MFMailComposeViewController
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: XI 8.6.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2015-01-13 11:41 UTC by tom.quist
Modified: 2015-01-14 10:55 UTC (History)
3 users (show)

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

Example project (7.72 MB, application/zip)
2015-01-13 11:41 UTC, tom.quist

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 tom.quist 2015-01-13 11:41:42 UTC
Created attachment 9339 [details]
Example project

When using a MFMailComposeViewController, it sometimes calls its delegate on a background thread (I don't know if this is intended behavior). Whenever that happens, the app calls UIKit methods on a background thread.

For a better understanding of the bug, check the example project, run it on a iOS 8.1 simulator, open the MFMailComposeViewController by clicking on the button and press CMD+K a couple of times. At some point the callback is called, which dismisses the view controller. Then the app crashes in CustomNavigationController in ChildViewControllerForStatusBarStyle() because it is called from a background thread.
Comment 1 Naqeeb 2015-01-13 13:18:14 UTC
I have tried to reproduce this issue and able to reproduce. I followed the below steps to reproduce this issue:

1. Downloaded attached project.
2. Open in XS.
2. Run the project on iOS 8.1 simulator.
3. Click on the 'Click me multiple times'  button.

I observed that after clicking on 'Click me multiple times'  button, application get crash with in few seconds and throws an exception. But here we need developer confirmation whether it is an issue or not. So as of now I am leaving this issue in NEW status.

Screencast : http://screencast.com/t/EToKmpz6wCX
Exception: https://gist.github.com/AkhileshKumar01/098b5b3513f00ffa6230
Application Output : https://gist.github.com/AkhileshKumar01/81b4fecd930fd2225cce
IDE log: https://gist.github.com/AkhileshKumar01/967455cc8cfa1ed724c5

Environment info : 
=== Xamarin Studio ===

Version 5.7 (build 661)
Installation UUID: ff0c16c6-3c75-46d8-ac56-56c3b56e2c76
	Mono 3.12.0 ((detached/a813491)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000068

=== Apple Developer Tools ===

Xcode 6.1.1 (6611)
Build 6A2008a

=== Xamarin.iOS ===

Version: (Trial Edition)
Hash: dfb682f
Build date: 2015-01-08 13:39:32-0500

=== Xamarin.Android ===

Version: (Indie Edition)
Android SDK: /Users/360_macmini/Desktop/android-sdk-macosx
	Supported Android versions:
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.1    (API level 12)
		4.0    (API level 14)
		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.Mac ===

Version: (Indie Edition)

=== Build Information ===

Release ID: 507000661
Git revision: b70bab61da996da29045ea8ee8aed1a6faedbe78
Build date: 2015-01-05 16:31:31-05
Xamarin addins: 82f6c71490562d6cd125a09287f441902fdac3d7

=== Operating System ===

Mac OS X 10.10.1
Darwin Apples-iMac.local 14.0.0 Darwin Kernel Version 14.0.0
    Fri Sep 19 00:26:44 PDT 2014
    root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
Comment 2 Sebastien Pouliot 2015-01-14 10:26:44 UTC
@Tom, you're right. You cannot trust on which thread `mailComposeController:didFinishWithResult:error:` [1] will be called. It's often, but not always, the main thread. That's unfortunate but that's how (some versions of) iOS behave [2].

Your code is also doing the "right thing": you're making sure your own work will be on the main thread.

However the issue here is different. Apple is calling (not from the main thread) back into UIKit code - even if they say it's not thread safe (and it's not [3])

Anyway that triggers the (optional [4]) XI thread checks, which is what you're seeing - i.e. it does not, directly, comes from your code - it's still on a different, Apple owned, thread.

I'll try to find a workaround that does not involve turning the thread checks off (as they are useful in many other scenarios).

[1] That's the selector on which the Finished event is based.

[2] Part of it is because this is cross-process (the UI is presented from another process);

[3] I consider that an iOS bug - since Apple can't be sure about about the code it's calling (and they can't expect people to have UIKit-subclasses that are thread safe, unless they provide base classes that are);

[4] It's enabled by default only on debug builds.
Comment 3 Sebastien Pouliot 2015-01-14 10:55:42 UTC
Two possible workarounds are:

1. ensure you get the property from the main thread

        public override UIViewController ChildViewControllerForStatusBarStyle()
			UIViewController result = null;
			InvokeOnMainThread (() => {
				result = TopViewController;
			return result;

2. disable the thread check specifically for this case

	public override UIViewController ChildViewControllerForStatusBarStyle()
		UIApplication.CheckForIllegalCrossThreadCalls = false;
		var result = TopViewController;
		UIApplication.CheckForIllegalCrossThreadCalls = true;
		return result;
		return TopViewController;

Note: I'll file a bug report with Apple (and I encourage you to do the same) but, at best, it will solve the issue for future versions of iOS.