This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 53794 - Uncatchable exception when cancelling HTTP requests
Summary: Uncatchable exception when cancelling HTTP requests
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll (show other bugs)
Version: XI 10.4 (C9)
Hardware: All All
: High critical
Target Milestone: Untriaged
Assignee: Manuel de la Peña
URL:
Depends on:
Blocks:
 
Reported: 2017-03-22 17:55 UTC by Rich Zwaap
Modified: 2017-03-28 20:57 UTC (History)
7 users (show)

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


Attachments
Solution and source files containing repro app (10.74 KB, application/x-zip-compressed)
2017-03-22 17:55 UTC, Rich Zwaap
Details
Application run. (84.44 KB, image/png)
2017-03-23 16:20 UTC, Manuel de la Peña
Details
Application run. (83.29 KB, image/png)
2017-03-23 16:22 UTC, Manuel de la Peña
Details
crash-log (36.99 KB, text/plain)
2017-03-24 10:22 UTC, Manuel de la Peña
Details

Description Rich Zwaap 2017-03-22 17:55:28 UTC
Created attachment 20689 [details]
Solution and source files containing repro app

Cancelling HTTP requests that were sent via HttpClient.SendAsync with an HttpCompletionOption of ResponseHeadersRead sometimes throws the following uncatchable exception:

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
  at System.Net.Http.NSUrlSessionHandler+NSUrlSessionHandlerDelegate.DidReceiveData (Foundation.NSUrlSession session, Foundation.NSUrlSessionDataTask dataTask, Foundation.NSData data) [0x00008] in /Users/builder/data/lanes/3985/35d1ccd0/source/xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:267 

As the exception is not catchable, it provokes an application crash.

The conditions under which the exception occurs include:

1. Using NSUrlSessionHandler as the HttpMessageHandler for HttpClient
2. Cancellation of a request occurring after a call to HttpClient.SendAsync is initiated with HttpCompletionOption of ResponseHeadersRead
3. Cancellation occurring before the response body is read
4. Disposal of the HttpResponseMessage returned from HttpClient.SendAsync

The issue is not easily reproducible when issuing and cancelling requests one-at-a-time or under deterministic timing, as it only seems to happen when cancellation occurs at a particular point in the HTTP request/response cycle.  It can, however, be reproduced when issuing and cancelling batches of requests with variable timing.  A test application that does so and reliably reproduces the issue is attached.  To repro, simply run the test application and click the "Start Test" button.  The issue should reproduce within a few seconds, and occurs regardless of the toggle state of the switch for including a cancellation token in the SendAsync call.  Anecdotally, the issue does seem to occur with less frequency when the cancellation token is included.

Note that this issue is specific to Cycle 9.  It was reproduced with both Cycle 9 RTM and SR0, but is not reproducible when the test app is built with the most recent Cycle 8 release.  The issue is reproducible on both simulators and physical devices.
Comment 1 Sebastien Pouliot 2017-03-23 12:36:28 UTC
Thanks for supplying a test case, this will help a lot. Manuel will be checking this shortly.

A possible, immediate workaround would be to use the CFNetwork-based handler or (worse case) the managed handler.
Comment 2 Manuel de la Peña 2017-03-23 16:20:31 UTC
Created attachment 20764 [details]
Application run.

Hello,

I can confirm the issue with the NSUrlSessionHandler, after looking at the source code I have proposed the following pr with a fix:

https://github.com/xamarin/xamarin-macios/pull/1900

After the fix I can run the application for a "long" amount of time and the exception does not longer occur and the application runs with no issues (screenshot attached).

As I understand it, this is what the application should do if no exceptions are raised, is this correct?
Comment 3 Manuel de la Peña 2017-03-23 16:22:13 UTC
Created attachment 20765 [details]
Application run.

This is the other run with the other mode.
Comment 4 Rich Zwaap 2017-03-23 17:36:36 UTC
> this is what the application should do if no exceptions are raised, is this correct?

Yes.  Without the NSUrlSessionHandler issue, requests should be made continuously until the application is exited.
Comment 5 Sebastien Pouliot 2017-03-23 22:03:41 UTC
PR merged in https://github.com/xamarin/xamarin-macios/commit/df29ecfff2f5a32773c43fea22d68031d55d0361

Testing will be done overnight on two devices.

PR for _consideration_ in d15.1 https://github.com/xamarin/xamarin-macios/pull/1904
Comment 6 Manuel de la Peña 2017-03-24 10:22:27 UTC
Created attachment 20784 [details]
crash-log

I have ran the test application overnight in two different devices (iPad 2 and iPhone 7). The application ran until it crash with an unrelated issue. (log attached).

I believe that this bug has been already fixed.
Comment 7 Sebastien Pouliot 2017-03-24 15:25:55 UTC
PR for cycle9 (potential hotfix candidate) https://github.com/xamarin/xamarin-macios/pull/1908
Comment 8 Sebastien Pouliot 2017-03-24 18:56:22 UTC
The following is a link to the C9-based build of the fix.

https://bosstoragemirror.blob.core.windows.net/wrench/macios-mac-cycle9/97/97eba398dcbf4401b4be297dab04170d9ba64466/xamarin.ios-10.4.0.131.pkg

This has not been thru QA yet, but this fix is the only changes from C9SR0 currently on our stable channel.

If you try this please let us know about your results. Thanks!
Comment 9 Morten Nielsen 2017-03-27 17:09:27 UTC
One of our customers just reported that this seems to resolve the issue for them.
Comment 10 Rich Zwaap 2017-03-27 17:44:16 UTC
This appears to fix the issue in my testing as well.  Thank you for the quick turnaround.

Are you able to say when we might expect a release that contains this fix?  This issue means that any of our customers who need to build Xamarin iOS apps are in the position of needing to downgrade to or stay on Cycle 8 for now.
Comment 11 Sebastien Pouliot 2017-03-27 17:47:54 UTC
@Rich we had plan to release this as an hotfix (to C9) as soon as QA confirms it.

Since Apple is releasing Xcode 8.3 today it might be delayed by a few days, or if QA confirms it, be part of XI 10.6.
Comment 12 Morten Nielsen 2017-03-27 17:49:23 UTC
I think waiting for 8.3 is totally acceptable. Your turnaround time has been nothing but admirable.
Comment 13 GouriKumari 2017-03-27 19:50:14 UTC
I could reproduce the issue with Xamarin.iOS 10.5.99.16 (xcode8.3: 370f0b6c) and cycle9SR0 stable on device and simulator, by setting the HttpClientImplementation of testapp to "NSUrlSession". In both cases app failed to run after a couple of seconds.
 
##Build Log: https://gist.github.com/GouriKumari/1f682ae339ad62b99e5985e48ea01ff6

With XI master build,  Xamarin.iOS 10.9.0.288 (master: 57cfbb2) , app continued to run on device and simulator with HttpClient implementation set to NSUrlSession without any application crash.

## Build Log: https://gist.github.com/GouriKumari/7ce8c4b08faeab8c844615c0928aba6d

## Verified Test Env:
Xamarin.iOS 10.9.0.288 (master: 57cfbb2).
Comment 14 Manuel de la Peña 2017-03-28 09:26:55 UTC
@Gouri I believe we did not back port the fix yet, @sebastien is that correct?

PS: Small comment, AFAIK there is no need to change the settings in the build since the app explicitly uses the NSUrlSessionHandler (it is passed to the constructor).
Comment 15 Sebastien Pouliot 2017-03-28 18:45:03 UTC
@Manuel it's been backported - the links to the PR are in the comments above.
Comment 16 GouriKumari 2017-03-28 20:57:13 UTC
Verified with XI 10.6.0.10.pkg and the issue is fixed. Tested with Simulator and device. I checked the test app without changing any settings in the project options.

## Logs:
Build Log: https://gist.github.com/GouriKumari/dcf90f49ea3f049446503636bdd79f30
Application Output: https://gist.github.com/GouriKumari/d476c7df14f51bc9d11b87cb3a29d5f5

##Test Env:
=== Xamarin Studio Enterprise ===

Version 6.2.1 (build 3)
Installation UUID: 5ed3a124-4b77-4c6f-beb9-c830fd815e2a
Runtime:
	Mono 4.8.0 (mono-4.8.0-branch/8f6d0f6) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 408000520

=== NuGet ===

Version: 3.5.0.0

=== Xamarin.Profiler ===

Version: 1.2.1
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 8.3 (12169)
Build 8E162

=== Xamarin.Mac ===

Version: 3.0.0.398 (Visual Studio Enterprise)

=== Xamarin Inspector ===

Version: 1.2.0
Hash: 62c17e6
Branch: d15-1
Build date: Mon, 20 Mar 2017 02:36:23 GMT

=== Xamarin.iOS ===

Version: 10.6.0.10 (Visual Studio Enterprise)
Hash: e66c6f19
Branch: xcode8.3
Build date: 2017-03-28 00:48:33-0400

=== Xamarin.Android ===

Version: 7.1.0.43 (Visual Studio Enterprise)
Android SDK: /Users/gourikumari/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		6.0 (API level 23)

SDK Tools Version: 25.2.3
SDK Platform Tools Version: 25.0.1
SDK Build Tools Version: 25.0.1

Java SDK: /usr
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Xamarin Android Player ===

Not Installed

=== Build Information ===

Release ID: 602010003
Git revision: 5217903c99e9d9c5d3caa2498fd66d607debac29
Build date: 2017-03-23 12:36:46-04
Xamarin addins: 2c96d252b353fce2e8b8fd20884eee70c16c7f32
Build lane: monodevelop-lion-cycle9

=== Operating System ===

Mac OS X 10.12.2

Note You need to log in before you can comment on or make changes to this bug.