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:
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.
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.
Created attachment 20764 [details]
I can confirm the issue with the NSUrlSessionHandler, after looking at the source code I have proposed the following pr with a fix:
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?
Created attachment 20765 [details]
This is the other run with the other mode.
> 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.
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
Created attachment 20784 [details]
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.
PR for cycle9 (potential hotfix candidate) https://github.com/xamarin/xamarin-macios/pull/1908
The following is a link to the C9-based build of the fix.
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!
One of our customers just reported that this seems to resolve the issue for them.
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.
@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.
I think waiting for 8.3 is totally acceptable. Your turnaround time has been nothing but admirable.
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).
@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).
@Manuel it's been backported - the links to the PR are in the comments above.
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.
Build Log: https://gist.github.com/GouriKumari/dcf90f49ea3f049446503636bdd79f30
Application Output: https://gist.github.com/GouriKumari/d476c7df14f51bc9d11b87cb3a29d5f5
=== Xamarin Studio Enterprise ===
Version 6.2.1 (build 3)
Installation UUID: 5ed3a124-4b77-4c6f-beb9-c830fd815e2a
Mono 4.8.0 (mono-4.8.0-branch/8f6d0f6) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 408000520
=== NuGet ===
=== Xamarin.Profiler ===
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Apple Developer Tools ===
Xcode 8.3 (12169)
=== Xamarin.Mac ===
Version: 126.96.36.1998 (Visual Studio Enterprise)
=== Xamarin Inspector ===
Build date: Mon, 20 Mar 2017 02:36:23 GMT
=== Xamarin.iOS ===
Version: 10.6.0.10 (Visual Studio Enterprise)
Build date: 2017-03-28 00:48:33-0400
=== Xamarin.Android ===
Version: 188.8.131.52 (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:
=== Xamarin Android Player ===
=== 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
Notice (2018-05-21): bugzilla.xamarin.com will be
switching to read-only mode on Thursday, 2018-05-25 22:00 UTC.
Please join us on
Visual Studio Developer Community and
GitHub to continue tracking
issues. Bugzilla will remain available for reference in read-only mode.
We will continue to work on open Bugzilla bugs and copy them to the new
locations as needed for follow-up. The See Also field
on each Bugzilla bug will be updated with a link to its new location
After Bugzilla is read-only, if you have new information to add for a
bug that does not yet have a matching issue on Developer Community or
GitHub, you can create a follow-up issue in the new location. Copy and
paste the title and description from this bug, and then add your new
details. You can get a pre-formatted version of the title and
In special cases you might also want the comments:
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.