Bug 61002 - Runtime exception: Cannot access a disposed object. Object name: 'MobileAuthenticatedStream'.
Summary: Runtime exception: Cannot access a disposed object. Object name: 'MobileAuthe...
Status: VERIFIED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: System (show other bugs)
Version: 5.8 (2017-10)
Hardware: Macintosh Mac OS
: High major
Target Milestone: 15.6
Assignee: Bugzilla
URL:
: 61003 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-06 13:56 UTC by veselev
Modified: 2018-02-23 06:17 UTC (History)
43 users (show)

See Also:
Tags:
Is this bug a regression?: Yes
Last known good build: Xamarin 15.4 Release


Attachments
Test case (1.01 KB, text/plain)
2017-12-22 05:35 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details
XamarinTestCases (387.15 KB, application/zip)
2018-01-17 04:51 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details

Description veselev 2017-12-06 13:56:04 UTC
During debug at runtime I get exception: Cannot access a disposed object. Object name: 'MobileAuthenticatedStream'.

Stacktrace:
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Library/Frameworks/Xamarin.iOS.framework/Versions/11.4.0.214/src/mono/mcs/class/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:152 
  at Mono.Net.Security.MobileAuthenticatedStream+<StartOperation>d__58.MoveNext () [0x001b9] in /Library/Frameworks/Xamarin.iOS.framework/Versions/11.4.0.214/src/mono/mcs/class/System/Mono.Net.Security/MobileAuthenticatedStream.cs:380
Comment 1 Timothy Risi 2017-12-06 17:47:16 UTC

*** This bug has been marked as a duplicate of bug 61003 ***
Comment 2 Carl Fauteux 2017-12-06 21:24:37 UTC
This bug is marked as a duplicate of 61003, but that other bug is unaccessible...
Would be nice to have a bit more information about the issue.
Comment 3 David Wolf 2017-12-07 14:18:19 UTC
I'm having the same issue since the latest update.

I get reports from Xamarin Insights with the exact same stack trace.
The App is NOT crashing but i get crash reports on every usage.

I'm currently using:

Visual Studio for Mac: 7.3 (build 797)
Mono: 5.4.1.7
Xamarin.iOS : 11.4.0.214

If there is a resolved duplicate it would be nice to know what the solution is.
Comment 4 PM Lemay 2017-12-07 19:04:57 UTC
This seems to affect only IOS 11, same app on IOS 9 or 10 does not throw this error when going offline (losing connection). When this happens and I come back online, my app cannot restart our replications.

My workaround was to include 'Cannot access a disposed object. Object name: 'MobileAuthenticatedStream' error message in my offline checks so that we can correctly handle our replication restarts.

Waiting for fixes either from Xamarin or Apple
Comment 5 David Wolf 2017-12-08 09:49:25 UTC
I was able to fix this by using a higher version of TLS.

If you go to your project settings -> Build -> iOS Build

you will see a field called HttpClient implementation.
I set this to NSUrlSession (iOS 7+). After that my app didn't produce this
error anymore.

Just in case anyone wants to read more about it:
https://developer.xamarin.com/guides/cross-platform/transport-layer-security/

Hope this fixes your apps also.
Comment 6 David Wolf 2017-12-08 13:07:31 UTC
Sry for the false alarm.
I just saw that it only reduces the problem to what pm.lemay2 said.
When the user loses connection this problem still occurs.
Comment 7 Kartik Bansal 2017-12-12 05:18:01 UTC
We are also having the same issue since last night. Our apps are crashing.

Terminating app due to uncaught exception 'System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread.', reason: 'System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.ObjectDisposedException: Cannot access a disposed object. Object name: 'MobileAuthenticatedStream'. at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () <0x100d26fc0 + 0x00028> in <1f5960abbfdf4434802d3b8a03ded4fa#131c13c3d3320c8f835d6334c46ee77b>:0 at Mono.Net.Security.MobileAuthenticatedStream+<StartOperation>d__58.MoveNext () <0x10107e940 + 0x005ff> in <11d9c39308e745a19d77fd5ab241cd94#131c13c3d3320c8f835d6334c46ee77b>:0 --- End of inner exception stack trace --- ---> (Inner Exception #0) System.ObjectDisposedException: Cannot access a disposed object. Object name: 'MobileAuthenticatedStream'. at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () <0x100d26fc0 + 0x00028> in <1f5960abbfdf4434802d3b8a03ded4fa#131c13c3d3320c8f835d6334c46ee77b>:0 at Mono.Net.Security.MobileAuthenticatedStream+<StartOperation>d__58.MoveNext () <0x10107e940 + 0x005ff> in <11d9c39308e745a19d77fd5ab241cd94#131c13c3d3320c8f835d6334c46ee77b>:0 <---
Comment 8 Kartik Bansal 2017-12-12 05:18:55 UTC
Someone please make bug 61003 public, please. Says I do not have to access to it
Comment 9 jmelliadis 2017-12-13 14:15:38 UTC
We are having the same issue in our applications. Thankfully, the affected version was only in beta and I was able to pull it before too many people were affected. Can we please get a response on this issue and what is causing it?
Comment 10 jmelliadis 2017-12-13 15:10:21 UTC
Has anyone tried to see if updating to Xamarin.iOS 11.6 fixes this issue?
Comment 11 David Wolf 2017-12-13 15:55:31 UTC
Yes i tried. But it didn't fix the issue.
Comment 12 Timothy Risi 2017-12-13 17:48:34 UTC
Re-opening this bug since it's public, will mark 61003 as the duplicate instead.
Comment 13 Timothy Risi 2017-12-13 17:49:18 UTC
*** Bug 61003 has been marked as a duplicate of this bug. ***
Comment 14 Manuel de la Peña [MSFT] 2017-12-14 13:08:43 UTC
@Timothy I'm increasing the importance and will talk to see which cycle we want to try and land the fix.
Comment 15 Sanjeev Dhavala 2017-12-15 08:26:31 UTC
Having same issue in Production-ready build. Request to release a fix ASAP
Comment 16 Felipe Cantagalli 2017-12-15 14:27:41 UTC
I'm having the same issue after the last release.
Looks like it does not crash the app on UI thread.

The stacktrace I have is:

  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () <0x100e930bc + 0x00024> in <bdb3aaa208384edf9f1266721cf8f9c1#5b30c802040f9a4c6d1c1493f58dbec3>:0 
  at Mono.Net.Security.MobileAuthenticatedStream+<StartOperation>d__58.MoveNext () <0x101023e00 + 0x005ff> in <fc81bc57986f4d1eb3ccf442a0589629#5b30c802040f9a4c6d1c1493f58dbec3>:0
Comment 17 aed 2017-12-18 05:11:02 UTC
This is also on Xamarin.Android:

 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <dbec98d794ad45e2a6025bbad367d16b>:0 
  at Mono.Net.Security.MobileAuthenticatedStream+<StartOperation>d__58.MoveNext () [0x001bf] in <90144bc6d8ef4c428b5af1187cfff71d>:0 

What's the latest version of Mono/XA which doesn't have this bug? This is a very frequent crash.
Comment 18 Ketra 2017-12-18 13:51:42 UTC
Also seeing this frequently on Android
Comment 19 Justin Toth 2017-12-18 16:45:46 UTC
We're seeing this crash in our iOS app too, and it's blocking us from releasing. A quick hot fix would be appreciated.
Comment 20 david 2017-12-18 23:41:00 UTC
We are also experiencing this issue at runtime in our deployed app. Thus far only on iOS but we get it on iOS 10 and not just on iOS 11. Not happening on our development versions though. Is it related to the version of Xcode used to compile the final app? (Dev uses Xcode 9.2, while our build machine is still on 9.0). Very much need either a) a proper fix or b) to know what version of the Xamarin toolchain is the latest that doesn't have this bug.
Comment 21 jmelliadis 2017-12-19 00:01:41 UTC
I was able to push out a version that is not experiencing this issue by downgrading to Xamarin.iOS 11.2 and to Xcode 9.
Comment 22 nmilcoff 2017-12-19 15:37:05 UTC
We're facing this issue on iOS.

Our stacktrace does not differ from others:

System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'MobileAuthenticatedStream'.

System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() in <1f5960abbfdf4434802d3b8a03ded4fa#f52df92212bf77893d7c0b27d24a3b65>:0
Mono.Net.Security.MobileAuthenticatedStream.StartOperation() in <11d9c39308e745a19d77fd5ab241cd94#f52df92212bf77893d7c0b27d24a3b65>:0
Comment 23 ry.lowry 2017-12-19 16:33:46 UTC
Also experiencing this problem on android, though it seems really hard to reproduce. Does anyone have any steps to trigger this problem? Its very deceptive because it doesn't seem to obviously crash the application, but the crash reports keep coming through.
Comment 24 Andy 2017-12-19 19:11:37 UTC
Experiencing on iOS
Comment 25 Brendan Zagaeski (Xamarin Team, assistant) 2017-12-20 04:20:52 UTC
## Preliminary context notes

To a first approximation based on studying the source code around the exception, I believe it indicates what one would guess: that some piece of the TLS communication is trying to run _after_ `MobileAuthenticatedStream` has been disposed.

The question is what has changed between the Mono 2017-04 branch and the Mono 2017-06 branch that could cause a difference in timing between `Dispose()` and the other methods on `MobileAuthenticatedStream`, and why didn't that same timing problem sometimes happen before?

To check one quick idea, I took to a glance to see if the changes to `MobileAuthenticatedStream` between those branches [1] might have added more calls to `Dispose()` for any scenarios.  But they don't.  There aren't any new calls to `Dispose()` (or `using()` for that matter), so no luck with that little idea.

[1] git diff 99b248fc6b47383bfc01c7c842ddff689d9d325b..b293f453027bc075ce636988b383451e5c346347 -- mcs/class/System/Mono.Net.Security/




## Next steps

It sounds like the original reporter from Comment 0 had an application that was (at least sometimes) demonstrating this issue locally during debugging.  If that user or anyone else on this report might be able to provide a source code test case, that would be excellent to help me with looking into this issue (particularly during these quieter last few weeks of December when the engineering team has less availability).  If the test case is small and easy to share publicly, feel free to attach it directly on this bug report.  Otherwise, you can share it privately with my email address (as listed on this comment) or share it with me on GitHub (https://github.com/brendanzagaeski/).  Or if you are using Visual Studio 2017 on Windows, another option is to attach it privately to a new Developer Community problem report via "Help > Send Feedback > Report a Problem" (up to 2 GB).

Thanks in advance!




## Additional background about the `ObjectDisposedException`

From Comment 0:
> mono/mcs/class/System/Mono.Net.Security/MobileAuthenticatedStream.cs:380

This matches up with the following line (from the current HEAD of the mono/d15-5-2017-06 branch):
https://github.com/mono/mono/blob/b293f453027bc075ce636988b383451e5c346347/mcs/class/System/Mono.Net.Security/MobileAuthenticatedStream.cs#L380

As one might expect, the `ObjectDisposedException` is created in the `MobileAuthenticatedStream.Dispose()` method:
https://github.com/mono/mono/blob/b293f453027bc075ce636988b383451e5c346347/mcs/class/System/Mono.Net.Security/MobileAuthenticatedStream.cs#L688

It is saved into the `MobileAuthenticatedStream.lastException` field so that it can later be thrown if one of the `try/catch` blocks from `InternalWrite()`, `InternalRead()`, `ProcessAuthentication()`, or `StartOperation()` catches an exception _after_ the stream has been disposed.
Comment 26 Brendan Zagaeski (Xamarin Team, assistant) 2017-12-20 04:40:27 UTC
## Cross-reference note for the Xamarin team

Non-public Bug 60387 shows the same exception message during a NuGet package restore operation in MonoDevelop on Linux.  It is not clear from that report how reproducible the exception might be in that scenario.
Comment 27 Brendan Zagaeski (Xamarin Team, assistant) 2017-12-20 22:19:57 UTC
## Brief status update

> during a NuGet package restore operation
I have been able to replicate this exception using a NuGet package restore operation in Visual Studio for Mac.  From my initial impressions, this seems like it will be a fairly reliable way to replicate the issue.  I will proceed to investigate based on this scenario.
Comment 28 Brendan Zagaeski (Xamarin Team, assistant) 2017-12-21 05:27:33 UTC
## Small update

I can force the `ObjectDisposedException` for `MobileAuthenticatedStream` to happen using the following console program based on the test case from Bug 55872.  This test case is roughly similar to what NuGet restore does: dispatching multiple requests in parallel, and canceling and retrying some of them if they exceed a timeout [1].  With Mono 5.2 (from the "d15-3" branch, based on the 2017-04 branch), it seems that the exception for `MobileAuthenticatedStream` never gets thrown, unlike in Mono 5.4 (from the "2017-06" branch).  But `ObjectDisposedException`s are thrown for `System.Net.Sockets.Socket` and `System.Net.Sockets.NetworkStream` in _both_ versions.

It seems that these exceptions are usually _handled_ within the network stack itself and not surfaced as _unhandled_ exceptions.  So far I haven't gotten an _unhandled_ `ObjectDisposedException` for `MobileAuthenticatedStream` with the console program at all, though I have seen unhandled object disposed exceptions for `System.Net.Sockets.Socket` and `System.Net.Sockets.NetworkStream`.

Preliminary experimentation with the console program suggests that the refactoring work related to Bug 55872 might help with this Bug 61002 as well: I did not get _any_ unhandled exceptions when using the latest development builds of desktop Mono [2] that include that candidate work.

[1] https://github.com/NuGet/NuGet.Client/blob/8a38fe7c21a1af9a1dc4c388ec67cce02c4bb76f/src/NuGet.Core/NuGet.Protocol/HttpSource/HttpRetryHandler.cs#L82
[2] https://jenkins.mono-project.com/job/build-package-osx-mono/job/master/

This still leaves a question of what has really changed for the final applications produced using the Mono "2017-06" branch compared to the "d15-3" branch that is causing a _new_ problem to show up in exception logs from Insights.  The console test program so far does not yet answer this question since it throws unhandled exceptions on both Mono versions.




## Next steps

I will return to looking at the NuGet restore scenario to see if it is possible to determine whether the Visual Studio for Mac logs that indicate unhandled `ObjectDisposedException`s for `MobileAuthenticatedStream` are accurate.




## Console program

```
public static void Main (string [] args)
{
    Run().Wait();
    Console.WriteLine("done");
}

public async static Task Run()
{
    HttpClient httpClient = new HttpClient();

    for (var i = 0; i < 10; i++) {
        var cts = new CancellationTokenSource();
        Task.Run(() => cts.CancelAfter(2));
        for (var j = 0; j < 20; j++) {
            httpClient.SendAsync(new HttpRequestMessage(HttpMethod.Get, "https://localhost"),cts.Token);
        }
        var response = await httpClient.SendAsync(new HttpRequestMessage(HttpMethod.Get, "https://localhost"));
    }
}
```
Comment 29 Brendan Zagaeski (Xamarin Team, assistant) 2017-12-22 05:35:17 UTC
Created attachment 26039 [details]
Test case

## Update

It turns out that the `ObjectDisposedException`s I saw when using exceptions breakpoints with the test case from Comment 28 _were_ the problematic exceptions.  What I was missing was the clue from Comment 7 that these "bad" exceptions are _unobserved_ rather than unhandled.
  (https://blogs.msdn.microsoft.com/pfxteam/2011/09/28/task-exception-handling-in-net-4-5/).

I modified the test console program accordingly (attached) and studied the problem a bit more.




## Regression status: regression introduced by mono/2017-06 commit 1b5e0f7 (21d5c9c on master)

Commit 1b5e0f7 [1] changed the asynchronous style of several methods in `MobileAuthenticatedStream`.  In particular, `StartOperation()` was refactored to return a `Task` rather than an `int`.  This change introduced the possibility of an unobserved exception.

Before this commit, `StartOperation()` was called synchronously in:
void Flush ()
void Close ()
int ProcessReadOrWrite ()

After the commit, it is called asynchronously in:
Task ShutdownAsync () 
IAsyncResult BeginRead ()
IAsyncResult BeginWrite ()
Task<int> ReadAsync ()
Task WriteAsync ()

Out of these methods, the console test program only hits `IAsyncResult BeginWrite()`.  Based on some initial experimentation, it seems that the problem might be that the corresponding `MobileAuthenticatedStream.EndWrite()` isn't called to observe the exceptions from `BeginWrite()`.  I will continue to investigate.

(To follow up briefly on the role of the refactoring work related to Bug 55872, I'll note that that work does _change_ the failure scenario of this test case, but it does not completely solve it.  When running under that candidate code, the test case hits unobserved "The request was canceled." `WebException`s rather than `ObjectDisposedException`s.  I will file a separate follow-up bug for those different unobserved exceptions for the new refactored code.)




## References
[1] https://github.com/mono/mono/commit/1b5e0f73316ee7b83c8947bc738015443fabd7af
Comment 30 Brendan Zagaeski (Xamarin Team, assistant) 2017-12-28 05:43:41 UTC
> it seems that the problem might be that the corresponding
> `MobileAuthenticatedStream.EndWrite()` isn't called
This is indeed the issue.  After the usual exercise of over-thinking some possible solutions on Saturday, I eventually thought of a more straightforward approach on Sunday, and spent some time yesterday and today putting together a pull request (for the Mono 2017-10 branch as the first step):

mono/2017-10:
https://github.com/mono/mono/pull/6346

The pull request comment includes several additional details about how the problem happens for anyone who is curious.




## Next steps

- I will coordinate with the engineering team to see about getting this fix included in the upcoming Xamarin 15.6 Release as well as any potential future service releases for the Xamarin 15.5 Release.

- I will also circle back to file the follow-up issue against the Mono master branch for the other, different unobserved exceptions that I saw in that environment.
Comment 31 Cliff Cawley 2018-01-05 00:07:39 UTC
Any news on the progress of the release? We just released to production and now we're seeing these errors come into raygun :(
Comment 32 Sebastien Pouliot 2018-01-05 14:25:22 UTC
Mono was bumped over this fix in our d15-6 branch and this should be part of preview 3.
Closing for QA verification.
Comment 33 Brendan Zagaeski (Xamarin Team, assistant) 2018-01-10 01:38:57 UTC
## Commit tracking notes for d15-6 branches

> mono/mono:2017-10             commit: 4f8a31840ca0c791aca22d6890d0538895d6bd4f
> 
> xamarin/xamarin-macios:d15-6  commit: 9b106941a83f5f73c88b0f627850a9eb4791d438
> 
> xamarin/xamarin-android:d15-6 commit: 303b775170a13dd174bb44fceaa68897cf812f4a
> xamarin/monodroid:d15-6       commit: b6dfc0ad4b4497738d5216f947c23c64d83e2c63
> xamarin/VisualStudio:d15-6    commit: [PR #161 in progress]
> Visual Studio 2017            commit: [in progress]



## Tracking notes for other branches

> mono/mono:d15-5-2017-06       PR for consideration: https://github.com/mono/mono/pull/6467
> 
> mono/mono:2017-12             PR in progress:       https://github.com/mono/mono/pull/6468
Comment 34 Brendan Zagaeski (Xamarin Team, assistant) 2018-01-10 04:12:13 UTC
## Cross-reference work item for Xamarin team internal tracking

https://devdiv.visualstudio.com/web/wi.aspx?pcguid=011b8bdf-6d56-4f87-be0d-0092136884d9&id=549510
Comment 35 Kartik Bansal 2018-01-15 07:41:08 UTC
Was the fix for this bug part of Jan 10th Xamarin.iOS v11.8 release?

I cannot see it here - https://developer.xamarin.com/releases/ios/xamarin.ios_11/xamarin.ios_11.8/
Comment 36 Rolf Bjarne Kvinge [MSFT] 2018-01-15 08:09:09 UTC
(In reply to Kartik Bansal from comment #35)
> Was the fix for this bug part of Jan 10th Xamarin.iOS v11.8 release?
> 
> I cannot see it here -
> https://developer.xamarin.com/releases/ios/xamarin.ios_11/xamarin.ios_11.8/

No, it was fixed too late. It will however be included in the next v11.8 alpha/beta release.
Comment 37 Brian Boccia 2018-01-16 23:53:35 UTC
So, is a 15-5 service release definitely out? Any target for when it'll be in the alpha/beta channels?
Comment 38 Brendan Zagaeski (Xamarin Team, assistant) 2018-01-17 00:43:27 UTC
> is a 15-5 service release definitely out?
It has not yet been strictly ruled out.  If it might be of interest, there are now un-QA'd candidate continuous integration packages of Xamarin.iOS, Xamarin.Mac, and Xamarin.Android that include the candidate change on top of the "d15-5" development branches.  See the latest "Artifact URLs" on:

https://jenkins.mono-project.com/view/Xamarin.MaciOS/job/macios-mac-d15-5/ (as of January 10)
https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-builds-d15-5/ (as of January 11)

Installation of these packages on macOS should work like other .pkg installers.  One complication is that the updater window in Visual Studio for Mac will offer downgrades if you have these packages installed, so you would need to ignore those notifications to continue using the candidate CI packages.

I haven't yet had a chance to try installation of a continuous integration version of the Xamarin.Android .vsix for Visual Studio 2017 on Windows.  It might work fairly smoothly too, installing on top of an existing Xamarin.Android installation and then offering a "Revert" button in the "Extensions and Updates" menu afterwards.

I will run some verification tests with these packages and update the bug with the latest commit tracking information accordingly.
Comment 39 Brendan Zagaeski (Xamarin Team, assistant) 2018-01-17 01:13:34 UTC
## Correction to Comment 38

... there are now un-QA'd candidate continuous integration packages of Xamarin.iOS, Xamarin.Mac, and Xamarin.Android that include the candidate change on top of the "d15-5" **and "xcode9.2"** development branches.  See the latest "Artifact URLs" on:

> Xamarin.iOS     https://jenkins.mono-project.com/view/Xamarin.MaciOS/job/xamarin-macios-builds-xcode9.2/
> Xamarin.Android https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-builds-d15-5/
> Xamarin.Mac     https://jenkins.mono-project.com/view/Xamarin.MaciOS/job/macios-mac-d15-5/
Comment 40 Brendan Zagaeski (Xamarin Team, assistant) 2018-01-17 04:51:56 UTC
Created attachment 26090 [details]
XamarinTestCases

(I have now checked that the continuous integration Xamarin.Android .vsix archive does install easily into Visual Studio 2017 and that Visual Studio does then offer a "Revert" button in "Tools > Extensions and Updates" that can restore the original version.)




## Verification status: verified for the test case from Comment 29 with the latest "d15-5" and "xcode9.2" CI builds

> GOOD: Xamarin.iOS 11.6         (xcode9.2: db807ec9) (CI build)
> BAD:  Xamarin.iOS 11.6.1.2     (xcode9.2: 6857dfcc)
> 
> GOOD: Xamarin.Android 8.1      (d15-5:    75f8c683) (CI build)
> BAD:  Xamarin.Android 8.1.3.0  (d15-5:    ef47226b)
> 
> GOOD: Xamarin.Mac 4.0          (d15-5:    de65bf22) (CI build)
> BAD:  Xamarin.Mac 4.0.0.215    (d15-5:    1bda16aa)
- The Xamarin.iOS package was tested both directly on macOS as well as remotely from Visual Studio 2017 version 15.5.2 on Windows using the test case in the "Debug | iPhoneSimulator" configuration.

- The Xamarin.Android .pkg package was tested directly on macOS using the test case in the "Release" configuration.

- The Xamarin.Android .vsix archive was tested in Visual Studio 2017 on Windows using the test case in the "Release" configuration.




## Internal supplementary bookkeeping info: package MD5 checksums

Xamarin.iOS     (xcode9.2: db807ec9)
a35dfe535419505582b42c73fd8f58ba

Xamarin.Android (d15-5:    75f8c683)
b4c0cfff6d73220913f4ca86a40e00e1

Xamarin.Mac     (d15-5:    de65bf22)
21b20fa16a8cf2ec9f86135e965251c7
Comment 41 pragma.mobilexp 2018-01-22 11:09:51 UTC
Any chance of getting this as service release hotfix for 15.5?  Seems like 15.6 stable is still quite some time off.  Don't want to release our beta update to production without fix included.
Comment 42 Brendan Zagaeski (Xamarin Team, assistant) 2018-01-22 16:24:47 UTC
> Any chance of getting this as service release ... for 15.5
A service release is under consideration based on the "good" CI packages mentioned in Comment 38 - Comment 40.  In this instance I won't be able to say with certainty whether a service release will be published until (and if) it is actually published, but it is fairly likely.
Comment 43 Brendan Zagaeski (Xamarin Team, assistant) 2018-01-24 00:09:00 UTC
## Updated commit tracking notes for d15-6 branches (for internal bookkeeping)

> xamarin/xamarin-android:d15-6 commit: 303b775170a13dd174bb44fceaa68897cf812f4a
> xamarin/monodroid:d15-6       commit: b6dfc0ad4b4497738d5216f947c23c64d83e2c63
> xamarin/VisualStudio:d15-6    commit: f38edcfa680c37edefa99d87ffb17f3006bc5b88
> Visual Studio 2017            commit: bc3559f1dde59b244185709efc2fc55b806f0001
Comment 44 John Miller [MSFT] 2018-01-25 21:50:11 UTC
The fix identified for this issue is now available as part of the 15.5.5 service release: https://releases.xamarin.com/service-release-15-5-5/
Comment 45 Ionita Andrei 2018-02-08 14:21:13 UTC
I'm still getting crash report on HockeyApp for the Android build:

android.runtime.JavaProxyThrowable: System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.ObjectDisposedException: Cannot access a disposed object. 
caused.AggregateException(s)
Object name: 'MobileAuthenticatedStream'.
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()<657aa8fea4454dc898a9e5f379c58734>:0
Mono.Net.Security.MobileAuthenticatedStream.<StartOperation>d__58.MoveNext()<9624f2cab6ac4ffc9c31e9469d40591a>:0
--- End of inner exception stack trace ---
---> (Inner Exception #0) System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'MobileAuthenticatedStream'.
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()<657aa8fea4454dc898a9e5f379c58734>:0
Mono.Net.Security.MobileAuthenticatedStream.<StartOperation>d__58.MoveNext()<9624f2cab6ac4ffc9c31e9469d40591a>:0

My setup:

=== Visual Studio Community 2017 for Mac ===

Version 7.3.3 (build 7)
Installation UUID: c97a6c3a-047d-4777-8d9f-60c2c3c44588
Runtime:
	Mono 5.4.1.7 (2017-06/e66d9abbb27) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 504010007

=== NuGet ===

Version: 4.3.1.4445

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	2.0.0
	1.1.1
	1.0.4
SDK: /usr/local/share/dotnet/sdk/2.0.0/Sdks
SDK Versions:
	2.0.0
	1.0.3
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

'/Applications/Xamarin Profiler.app' not found

=== Apple Developer Tools ===

Xcode 9.2 (13772)
Build 9C40b

=== Xamarin.iOS ===

Version: 11.6.1.4 (Visual Studio Community)
Hash: db807ec9
Branch: xcode9.2
Build date: 2018-01-10 16:45:48-0500

=== Xamarin.Mac ===

Version: 4.0.0.216 (Visual Studio Community)

=== Xamarin.Android ===

Version: 8.1.5.0 (Visual Studio Community)
Android SDK: /Users/Andrei/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		4.4 (API level 19)
		6.0 (API level 23)
		7.1 (API level 25)

SDK Tools Version: 25.2.5
SDK Platform Tools Version: 25.0.4
SDK Build Tools Version: 23.0.2

Java SDK: /usr
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

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

=== Xamarin Inspector ===

Version: 1.4.0
Hash: b3f92f9
Branch: master
Build date: Fri, 19 Jan 2018 22:00:34 GMT
Client compatibility: 1

=== Build Information ===

Release ID: 703030007
Git revision: 125911fb4accc4309b2cee5c81c970c7cff9b0e0
Build date: 2018-01-22 17:46:46-05
Xamarin addins: 463e21a6d9d4f6b57f923df376fff093a1dd9404
Build lane: monodevelop-lion-d15-5

=== Operating System ===

Mac OS X 10.12.6
Darwin 16.7.0 Darwin Kernel Version 16.7.0
    Wed Oct  4 00:17:00 PDT 2017
    root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64

=== Enabled user installed addins ===

Internet of Things (IoT) development (Preview) 7.1
Comment 46 Brendan Zagaeski (Xamarin Team, assistant) 2018-02-10 01:00:03 UTC
Thanks for the notification about your incoming reports from HockeyApp.  I ran another round of verifications with Xamarin.Android 8.1.5 today using the test case from Comment 40.  I was unable to produce any unobserved exceptions for `MobileAuthenticatedStream` when using that version, so if any users are receiving telemetry for this exception from versions of their apps that were unequivocally built with Xamarin.Android 8.1.5 or higher, then we will need to collect additional data from those users.  The most direct approach would be if any user has a test case that still demonstrates the problem on Xamarin.Android 8.1.5 or higher and can attach it on a new report via "Report a Problem" in the IDE or via GitHub Issues.




## Testing details

I first re-confirmed that I was able to produce the unobserved exceptions using Xamarin.Android 8.1.3.  I then adjusted the project to test across a 400 ms range of cancellation times, in 20 ms increments, centered on the time that always produced exceptions in Xamarin.Android 8.1.3 (420 ms for my particular Android test device and network conditions).  I set the test to perform 40 canceled requests at each 20 ms increment.

I was unable to produce any unobserved exceptions under these conditions.

I then further stress-tested the candidate fix using desktop Mono with scenarios based on the test case from Bug 55872 and the test case from Bug 31507.  Before the fix, I was able to produce unobserved exceptions on every run for both scenarios.  After the fix, I was unable to produce any unobserved exceptions across a number of different combinations of cancellation timings, HTTPS endpoints, simultaneous requests, and POST versus GET requests.
Comment 47 juan.ignacio 2018-02-16 12:03:56 UTC
We are are also having this issued with last version of Xamarin Android with a similar configuration than Ionita Andrei.


Xamarin caused by: android.runtime.JavaProxyThrowable: System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'MobileAuthenticatedStream'.
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <f2e5cf4b023f45559616c3ae37007b6a>:0 
  at Mono.Net.Security.MobileAuthenticatedStream+<StartOperation>d__58.MoveNext () [0x001bf] in <bd13efcc966942708e9714b7e5dec818>:0 
   --- End of inner exception stack trace ---
---> (Inner Exception #0) System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'MobileAuthenticatedStream'.
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <f2e5cf4b023f45559616c3ae37007b6a>:0 
  at Mono.Net.Security.MobileAuthenticatedStream+<StartOperation>d__58.MoveNext () [0x001bf] in <bd13efcc966942708e9714b7e5dec818>:0 <---
Comment 48 Brendan Zagaeski (Xamarin Team, assistant) 2018-02-16 17:27:11 UTC
Hi,

I'm afraid Comment 47 does not address the questions raised in Comment 46.  For example, a couple questions for users to think about and answer when commenting on this bug report are:

1. Are you sure that the application version that is producing the unobserved exception was built with Xamarin.Android 8.1.5 or higher or Xamarin.iOS 11.6.1.4 or higher?
2. How are you sure of the Xamarin version?  What small evidence can you provide in your comment to demonstrate that the application version producing the exception was definitely built with one of these versions that includes the change from Comment 30?

Thanks!
Brendan

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