Bug 22004 - Breakpoint set within async code crashes debugger when using Task.Run
Summary: Breakpoint set within async code crashes debugger when using Task.Run
Alias: None
Product: iOS
Classification: Xamarin
Component: Debugger ()
Version: 7.2.6
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
: 21855 ()
Depends on:
Reported: 2014-08-11 12:04 UTC by Mike Perry
Modified: 2014-09-18 12:38 UTC (History)
6 users (show)

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

Test project with code from comment 3 (2.67 MB, application/zip)
2014-08-18 14:58 UTC, Jon Goldberger [MSFT]
Test Project with code from comment 3 (2.52 MB, application/zip)
2014-08-18 15:02 UTC, Jon Goldberger [MSFT]

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 Mike Perry 2014-08-11 12:04:22 UTC
When debugging async code, debugger detaches and native stack trace appears in the app output window. This only happens when debugging. When running the app, the simulator does not crash. This only started happening after updating to monotouch 

I've isolated this to instances where a Task is created inline and executed, containing an async method call:

Code that crashes the debugger when breakpoint set inside _authenService.Authenticate:

var loginResult = await Task.Run (async () => {
				try {
					return await _authService.Authenticate (container.Identity);
				catch {
					return null;

Changing the code to the following allows the debugger to step through code, and the simulator does not crash:

try {
				//Attempt login
				var loginResult = await _authService.Authenticate (container.Identity);
				container.UserContext = loginResult;
			catch(Exception ex) {
				return null;
                        return container;

Between these 2 tests I rebuilt the application, and reset the simulator.

Granted, the code that's failing is not ideal and contains unnecessary lines, but a hard crash and native stack trace is not an ideal result.

Example of native stacktrace appearing in output window:

Resolved pending breakpoint at '/Users/michaelperry/development/JCI Production Build/JCI.BE.SmartBuilding.SETMobile/Core/Services/AuthenticationService.cs:24,1' to void JCI.BE.SmartBuilding.SETMobile.Core.Services.AuthenticationService.<Authenticate>c__async0.MoveNext () [0x00022].
* Assertion at ../../../../../mono/mono/mini/debugger-agent.c:7703, condition `mono_error_ok (&error)' not met

mono-rt: Stacktrace:

Native stacktrace:

mono-rt: 	0   PresentationiOS                     0x002ee0cc mono_handle_native_sigsegv + 300

mono-rt: 	1   PresentationiOS                     0x002fa37a sigabrt_signal_handler + 122

mono-rt: 	2   libsystem_platform.dylib            0x05c62deb _sigtramp + 43

mono-rt: 	3   ???                                 0xffffffff 0x0 + 4294967295

mono-rt: 	4   libsystem_sim_c.dylib               0x05aab9c9 abort + 127

mono-rt: 	5   PresentationiOS                     0x00446c35 monoeg_g_logv + 181

mono-rt: 	6   PresentationiOS                     0x00446c9b monoeg_assertion_message + 43

mono-rt: 	7   PresentationiOS                     0x0026b8ba buffer_add_cattrs + 1834

mono-rt: 	8   PresentationiOS                     0x00269d5b method_commands_internal + 4907

mono-rt: 	9   PresentationiOS                     0x00261622 debugger_thread + 4802

mono-rt: 	10  PresentationiOS                     0x0043b670 inner_start_thread + 240

mono-rt: 	11  PresentationiOS                     0x0045ee9d GC_start_routine + 93

mono-rt: 	12  libsystem_pthread.dylib             0x05d545fb _pthread_body + 144

mono-rt: 	13  libsystem_pthread.dylib             0x05d54485 _pthread_struct_init + 0

mono-rt: 	14  libsystem_pthread.dylib             0x05d59cf2 thread_start + 34

Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
Comment 1 Alex Soto [MSFT] 2014-08-12 01:51:50 UTC
Hello I could not duplicate using code similar to yours (comment #1)

		int seconds = 5;
		async partial void btnWait_TouchUpInside (UIButton sender)
			var result = await Task.Run (async () =>  {
				try {
					return await WaitXSeconds (seconds);
				} catch (Exception ex) {
					return -1;
			new UIAlertView ("Waited", "Waited for " + result, null, "Ok", null).Show ();

		async Task<int> WaitXSeconds (int secs)
			await Task.Run (() => {
				Thread.Sleep (secs + 1000);
				Console.WriteLine ("finished waiting");
			return secs;

Please attach a self-contained test case, i.e. that might only happen for some
libraries and not the test case I made.
Comment 2 Borislav Parvanov 2014-08-14 12:39:24 UTC
using System;
using System.Threading.Tasks;
using Xamarin.Forms;

namespace TestXamForms
	public class MainPage : ContentPage
		bool flag;

		public MainPage ()
			ListView listview = null;

			// NOTE: it won't crash if you comment next 4 lines
			Button btn = new Button ();
			btn.Clicked += (object sender, EventArgs e) => {
				listview.SelectedItem = null;
			// ~NOTE

			var toolbarItem = new ToolbarItem ("Click Me!", null, async () => {
				//await Task.Delay(1000); // it won't crash if you uncomment this line
				if (flag) // <--- set break point here

			this.ToolbarItems.Add (toolbarItem);

	public class App
		public static Page GetMainPage ()
			var mainPage = new NavigationPage (new MainPage());

			return mainPage;
Comment 4 Jon Goldberger [MSFT] 2014-08-18 14:27:30 UTC
Might be a dup of: https://bugzilla.xamarin.com/show_bug.cgi?id=21855
Comment 5 Jon Goldberger [MSFT] 2014-08-18 14:34:02 UTC
I was able to replicate this issue using the code in Comment 2. 

I noted that uncommenting the line noted in the code snippet avoided the crash. I also noted that with:

await Task.Delay(x);

if x < 3 then I get a crash. With x >=3, no crash. 

I also noted that just commenting out the 

listview.SelectedItem = null;

line in the btw.Clicked event handler avoided the crash, i.e. it was unnecessary to uncomment all four lines of code as noted. (Tested this with the "await Task.Delay(x);" line commented out)
Comment 6 Jon Goldberger [MSFT] 2014-08-18 14:34:24 UTC
My version info:
=== Xamarin Studio ===

Version 5.2.1 (build 1)
Installation UUID: 2dc9022f-f9a8-424f-8284-bf224cbbfde0
	Mono 3.6.0 ((no/f540f8a)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 306000039

=== Apple Developer Tools ===

Xcode 5.1.1 (5085)
Build 5B1008

=== Xamarin.Mac ===


=== Xamarin.Android ===

Version: 4.14.0 (Business Edition)
Android SDK: /Users/apple/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		3.2   (API level 13)
		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)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 606f31a
Build date: 2014-08-01 15:27:48-0400

=== Build Information ===

Release ID: 502010001
Git revision: d06832ce9807d6be24aca225457e8b37c7669f6f
Build date: 2014-08-07 12:10:47-04
Xamarin addins: 1de032531be4cecf2f39dbee3b87aac78204058c

=== Operating System ===

Mac OS X 10.9.4
Darwin Jonathans-MacBook-Pro.local 13.3.0 Darwin Kernel Version 13.3.0
    Tue Jun  3 21:27:35 PDT 2014
    root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
Comment 7 Alex Soto [MSFT] 2014-08-18 14:35:35 UTC
Thanks @Borislav

@Jon Can you attach the sample project you did in order to replicate the issue?
Comment 8 Jon Goldberger [MSFT] 2014-08-18 14:58:20 UTC
Created attachment 7710 [details]
Test project with code from comment 3

This is a Xamarin Forms template project with the code from comment 3 replacing the code in App.cs.
Comment 9 Zoltan Varga 2014-08-18 14:59:07 UTC
This is a dup of #21653.
Comment 10 Jon Goldberger [MSFT] 2014-08-18 15:02:02 UTC
Created attachment 7711 [details]
Test Project with code from comment 3

Replacing attachment 7710 [details]. Thisversion has the commenting set to allow the app to crash .
Comment 11 Alex Soto [MSFT] 2014-09-02 21:11:19 UTC
Fixed in mono master 766e8c350413870ac2ddd4c4b03f3259b96c509f.  By Zoltan.
Comment 12 Rolf Bjarne Kvinge [MSFT] 2014-09-18 12:38:11 UTC
*** Bug 21855 has been marked as a duplicate of this bug. ***