| Summary: | Uncatchable exception when cancelling HTTP requests | ||
|---|---|---|---|
| Product: | iOS | Reporter: | Rich Zwaap <rzwaap> |
| Component: | Xamarin.iOS.dll | Assignee: | Manuel de la Peña [MSFT] <manuel.delapena> |
| Status: | VERIFIED FIXED | ||
| Severity: | critical | CC: | alex.blount, gouri.kumari, miguel, mnielsen, mono-bugs+monotouch, rzwaap, sebastien |
| Priority: | High | ||
| Version: | XI 10.4 (C9) | ||
| Target Milestone: | Untriaged | ||
| Hardware: | All | ||
| OS: | All | ||
| Tags: | Is this bug a regression?: | --- | |
| Last known good build: | |||
| Attachments: |
Solution and source files containing repro app
Application run. Application run. crash-log |
||
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] 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? Created attachment 20765 [details]
Application run.
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]
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.
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. 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! 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. ## 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 |
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.