Bug 44628 - SocketAsyncResult IsComplete ObjectDisposedException
Summary: SocketAsyncResult IsComplete ObjectDisposedException
Status: RESOLVED DUPLICATE of bug 44629
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: 4.4.2 (C7SR1)
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-09-22 16:33 UTC by Oliver
Modified: 2016-09-23 07:00 UTC (History)
2 users (show)

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

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:
Status:
RESOLVED DUPLICATE of bug 44629

Description Oliver 2016-09-22 16:33:54 UTC
I've been having issues where I will encounter an exception which can't be caught which crashes my program.

Unhandled Exception:
 System.ObjectDisposedException: Cannot access a disposed object.
 Object name: 'System.Threading.ManualResetEvent'.
   at System.Threading.WaitHandle.CheckDisposed () [0x00043] in /mono/mcs/class/corlib/System.Threading/WaitHandle.cs:435 
   at System.Threading.EventWaitHandle.Set () [0x0000c] in /mono/mcs/class/corlib/System.Threading/EventWaitHandle.cs:205 
   at (wrapper remoting-invoke-with-check) System.Threading.EventWaitHandle:Set ()
   at System.IOAsyncResult.set_IsCompleted (Boolean value) [0x00024] in /mono/mcs/class/System/System/IOSelector.cs:118 
   at System.Net.Sockets.SocketAsyncResult.Complete () [0x00044] in /mono/mcs/class/System/System.Net.Sockets/SocketAsyncResult.cs:146 
   at System.Net.Sockets.SocketAsyncResult.Complete (System.Exception e) [0x00007] in /mono/mcs/class/System/System.Net.Sockets/SocketAsyncResult.cs:214 
   at System.Net.Sockets.Socket.<BeginConnectCallback>m__4 (System.IOAsyncResult ares) [0x0012a] in /mono/mcs/class/System/System.Net.Sockets/Socket.cs:1579 
   at System.IOSelectorJob.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00000] in /mono/mcs/class/System/System/IOSelector.cs:143 
   at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00096] in /mono/external/referencesource/mscorlib/system/threading/threadpool.cs:857 
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in /mono/external/referencesource/mscorlib/system/threading/threadpool.cs:1212

I managed to trace the issue down to a call that was made in the RabbitMQ.Client nuget package version 3.6.5 in the Connect method where AsyncWaitHandle.Close (which dipososes of the wait handle) is called. In some instances it appears this bit of code executes before the code called above and so an ObjectDisposedException occurs. I have tested this with mono 4.6 and have the same issue with a similar stacktrace, I'm not quite sure what the expected behaviour should be. I have been able to reproduce this issue by running rabbitmq, connecting to it and then pulling it down so the program can no longer connect, but it only happens every so often.

https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/rabbitmq_v3_6_5/projects/client/RabbitMQ.Client/src/client/impl/SocketFrameHandler.cs

private void Connect(ITcpClient socket, AmqpTcpEndpoint endpoint, int timeout)
{
    IAsyncResult ar = null;
    try
    {
        ar = socket.BeginConnect(endpoint.HostName, endpoint.Port, null, null);
        if (!ar.AsyncWaitHandle.WaitOne(timeout, false))
        {
            socket.Close();
            throw new TimeoutException("Connection to " + endpoint + " timed out");
        }
        socket.EndConnect(ar);
    }
    catch (ArgumentException e)
    {
        throw new ConnectFailureException("Connection failed", e);
    }
    catch (SocketException e)
    {
        throw new ConnectFailureException("Connection failed", e);
    }
    finally
    {
        if (ar != null)
        {
            ar.AsyncWaitHandle.Close();
        }
    }
}
Comment 1 Marek Safar 2016-09-23 07:00:00 UTC

*** This bug has been marked as a duplicate of bug 44629 ***