Bug 10430 - Mono.Security.Protocol.Tls.SslStreamBase.InternalReadCallback should not ignore async results when it has been disposed.
Summary: Mono.Security.Protocol.Tls.SslStreamBase.InternalReadCallback should not igno...
Alias: None
Product: Class Libraries
Classification: Mono
Component: Mono.Security ()
Version: unspecified
Hardware: Macintosh Windows
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2013-02-19 06:18 UTC by Jahmai
Modified: 2017-10-12 13:12 UTC (History)
12 users (show)

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

Test case (40.20 KB, application/x-zip-compressed)
2013-07-21 00:10 UTC, Jahmai

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Jahmai 2013-02-19 06:18:13 UTC
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.
Comment 2 GouriKumari 2013-07-16 18:47:53 UTC
Jahmai ,

Could you also attach a testcase or a sample solution to reproduce this issue.
Comment 3 Miguel de Icaza [MSFT] 2013-07-20 10:55:20 UTC
Setting to NEEDINFO, we need a test case showing this problem so we can compare against the Windows behavior for streams.
Comment 4 Jahmai 2013-07-21 00:10:02 UTC
Created attachment 4388 [details]
Test case

Solution to show the test case.
Should open in both VS2012 and latest Xamarin Studio (as a Mono / .net Framework 4 program).
Comment 5 PJ 2013-11-19 16:44:50 UTC
This bug was targeted for a past milestone, moving to the next non-hotfix active milestone.
Comment 6 Jahmai 2014-03-28 03:56:56 UTC
The status of this shouldn't be NEEDINFO as the test case was attached a long time ago.
Comment 7 Jungmok Han 2015-04-21 11:37:41 UTC
@Jahmai Is the following stacktrace similar to your case?  After migrating to Unified API, we often ran into the issue.

at <0xffffffff>
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/
at Mono.Security.Protocol.Tls.RecordProtocol.decryptRecordFragment (Mono.Security.Protocol.Tls.ContentType,byte[]) [0x00004] in //Library/Frameworks/Xamarin.iOS.framework/Versions/
at Mono.Security.Protocol.Tls.RecordProtocol.ReceiveRecord (System.IO.Stream) [0x00099] in //Library/Frameworks/Xamarin.iOS.framework/Versions/
at Mono.Security.Protocol.Tls.SslStreamBase.InternalReadCallback (System.IAsyncResult) [0x00091] in //Library/Frameworks/Xamarin.iOS.framework/Versions/
at (wrapper runtime-invoke) object.runtime_invoke_dynamic (intptr,intptr,intptr,intptr) <0xffffffff>
Comment 8 GouriKumari 2016-01-11 22:30:41 UTC
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 ===

Not Installed

=== Xamarin.Android ===

Version: (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 ===

Not Installed

=== Apple Developer Tools ===

Xcode 7.2 (9548)
Build 7C68

=== Xamarin.Mac ===

Version: (Starter Edition)

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 28b5d0d
Branch: master
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
Comment 9 Al Clark [MSFT] 2017-07-26 13:45:10 UTC
Moving from XI to Mono Runtime. Doesn't appear to be iOS related.
Comment 10 Marek Safar 2017-10-12 13:12:00 UTC
I cannot reproduce the issue with Mono 5.4