Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
GitHub or Developer Community 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.
When working with async Stream's, often the only way to cancel a pending async call is to dispose the stream.
This causes any pending reads and writes to fail (usually with something along the lines of ObjectDisposedException).
It is important that if you have multiple layers of streams (e.g. GZip -> Ssl -> Network) that when you Dispose the top Stream that the calls to Dispose cascade down the chain cause a ripple effect of failed async operations back to the top of the chain.
In Mono.Security.Protocol.Tls.SslStreamBase.InternalReadCallback, where it deals with failed async reads from the inner stream, it simply returns, if the instance of SslStreamBase has been disposed.
Actually, what should happen is that the pending async operation should be completed (probably with an ObjectDisposedException).
If you do not do this, there are dangling async operations further up the chain that can cause objects to sit around for longer than they should, or for certain fault handling code to not be executed.
This is most obvious when using the C# await keyword (or calling the .Wait()/.Result members) along with the ReadAsync overload that uses the Task.Factory.FromAsync methods to create the task from the BeginRead/EndRead functions. What happens is that the IAsyncResult never completes and therefore the Task never completes.
Could you also attach a testcase or a sample solution to reproduce this issue.
Setting to NEEDINFO, we need a test case showing this problem so we can compare against the Windows behavior for streams.
Created attachment 4388 [details]
Solution to show the test case.
Should open in both VS2012 and latest Xamarin Studio (as a Mono / .net Framework 4 program).
This bug was targeted for a past milestone, moving to the next non-hotfix active milestone.
The status of this shouldn't be NEEDINFO as the test case was attached a long time ago.
@Jahmai Is the following stacktrace similar to your case? After migrating to Unified API, we often ran into the issue.
at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) <0xffffffff>
at Mono.Security.Protocol.Tls.CipherSuite.DecryptRecord (byte,byte&,byte&) [0x0003f] in //Library/Frameworks/Xamarin.iOS.framework/Versions/22.214.171.1248/src/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/CipherSuite.cs:330
at Mono.Security.Protocol.Tls.RecordProtocol.decryptRecordFragment (Mono.Security.Protocol.Tls.ContentType,byte) [0x00004] in //Library/Frameworks/Xamarin.iOS.framework/Versions/126.96.36.1998/src/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/RecordProtocol.cs:911
at Mono.Security.Protocol.Tls.RecordProtocol.ReceiveRecord (System.IO.Stream) [0x00099] in //Library/Frameworks/Xamarin.iOS.framework/Versions/188.8.131.528/src/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/RecordProtocol.cs:474
at Mono.Security.Protocol.Tls.SslStreamBase.InternalReadCallback (System.IAsyncResult) [0x00091] in //Library/Frameworks/Xamarin.iOS.framework/Versions/184.108.40.2068/src/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslStreamBase.cs:663
at (wrapper runtime-invoke) object.runtime_invoke_dynamic (intptr,intptr,intptr,intptr) <0xffffffff>
Verified with XI master builds.
Test Results: https://gist.github.com/GouriKumari/a1b73dccc2232732c28c
Moving this bug to another milestone.
## Test Env:
=== Xamarin Studio ===
Version 5.10.1 (build 6)
Installation UUID: 5ed3a124-4b77-4c6f-beb9-c830fd815e2a
Mono 4.2.1 (explicit/6dd2d0d)
GTK+ 2.24.23 (Raleigh theme)
Package version: 402010102
=== Xamarin.Profiler ===
=== Xamarin.Android ===
Version: 220.127.116.11 (Starter Edition)
Android SDK: /Users/gourikumari/Library/Developer/Xamarin/android-sdk-mac_x86
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.4 (API level 19)
SDK Tools Version: 22.6.3
SDK Platform Tools Version: 19.0.2
SDK Build Tools Version: 19.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)
=== Xamarin Android Player ===
=== Apple Developer Tools ===
Xcode 7.2 (9548)
=== Xamarin.Mac ===
Version: 18.104.22.168 (Starter Edition)
=== Xamarin.iOS ===
Version: 22.214.171.124 (Business Edition)
Build date: 2016-01-11 07:30:34-0500
=== Build Information ===
Release ID: 510010006
Git revision: 0b60eecdb531933734519c13257d16a780274aab
Build date: 2015-12-04 20:28:20-05
Xamarin addins: 9876fd7c9837977178411ec7375b4352c0a0d6af
Build lane: monodevelop-lion-cycle6-baseline
=== Operating System ===
Mac OS X 10.10.5
Moving from XI to Mono Runtime. Doesn't appear to be iOS related.
I cannot reproduce the issue with Mono 5.4