Calling SearchAsync produce random ObjectDisposedException as unhandled

Question

Calling SearchAsync produce random ObjectDisposedException as unhandled

Rambalac opened this issue 7 years ago · comments

Stack

>	System.Net.Sockets.dll!System.Net.Sockets.Socket.EndReceiveFrom(System.IAsyncResult asyncResult, ref System.Net.EndPoint endPoint)	Unknown
 	System.Net.Sockets.dll!System.Net.Sockets.SocketTaskExtensions.ReceiveFromAsync.AnonymousMethod__8_1(System.IAsyncResult asyncResult)	Unknown
 	System.Private.CoreLib.ni.dll!System.Threading.Tasks.TaskFactory<System.Net.Sockets.SocketReceiveFromResult>.FromAsyncCoreLogic(System.IAsyncResult iar, System.Func<System.IAsyncResult, System.Net.Sockets.SocketReceiveFromResult> endFunction, System.Action<System.IAsyncResult> endAction, System.Threading.Tasks.Task<System.Net.Sockets.SocketReceiveFromResult> promise, bool requiresSynchronization)	Unknown
 	System.Private.CoreLib.ni.dll!System.Threading.Tasks.TaskFactory<System.Net.Sockets.SocketReceiveFromResult>.FromAsyncImpl.AnonymousMethod__0(System.IAsyncResult iar)	Unknown
 	System.Net.Sockets.dll!System.Net.LazyAsyncResult.Complete(System.IntPtr userToken)	Unknown
 	System.Net.Sockets.dll!System.Net.ContextAwareResult.CompleteCallback()	Unknown
 	System.Net.Sockets.dll!System.Net.ContextAwareResult.Complete.AnonymousMethod__15_0(object s)	Unknown
 	System.Private.CoreLib.ni.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state)	Unknown
 	System.Net.Sockets.dll!System.Net.ContextAwareResult.Complete(System.IntPtr userToken)	Unknown
 	System.Net.Sockets.dll!System.Net.LazyAsyncResult.ProtectedInvokeCallback(object result, System.IntPtr userToken)	Unknown
 	System.Net.Sockets.dll!System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(uint errorCode, uint numBytes, System.Threading.NativeOverlapped* nativeOverlapped)	Unknown
 	System.Threading.Overlapped.dll!System.Threading.Win32ThreadPoolNativeOverlapped.OnExecutionContextCallback(object state)	Unknown
 	System.Private.CoreLib.ni.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state)	Unknown
 	System.Threading.Overlapped.dll!System.Threading.Win32ThreadPoolNativeOverlapped.CompleteWithCallback(uint errorCode, uint bytesWritten, System.Threading.Win32ThreadPoolNativeOverlapped* overlapped)	Unknown
 	System.Threading.Overlapped.dll!System.Threading.ThreadPoolBoundHandle.OnNativeIOCompleted(System.IntPtr instance, System.IntPtr context, System.IntPtr overlappedPtr, uint ioResult, System.UIntPtr numberOfBytesTransferred, System.IntPtr ioPtr)	Unknown

I'm using RSSDP for Windows 10 UWP app.

My init code

foreach (var host in confirmedHosts)
            {
                var deviceLocator =
                    new SsdpDeviceLocator(new SsdpCommunicationsServer(new SocketFactory(host.CanonicalName)))
                    {
                        NotificationFilter = "urn:schemas-upnp-org:device:MediaServer:1"
                    };
                deviceLocator.DeviceAvailable += DeviceLocator_DeviceAvailable;
                deviceLocator.StartListeningForNotifications();
                deviceLocators.Add(deviceLocator);
            }

And the call

try
            {
                foreach (var dev in deviceLocators)
                {
                    await dev.SearchAsync();
                }
            }
            catch (Exception e)
            {
                Log.Debug(e);
            }

And handler

        private async void DeviceLocator_DeviceAvailable(object sender, DeviceAvailableEventArgs arg)
        {
            try
            {
                ....
            }
            catch (Exception e)
            {
                Debug.WriteLine(e);
                Log.Error(e);
            }
        }

Removing the call stops unhandled exceptions

I have my own UDP receiver code using DatagramSocket and it has no such problem.

Rambalac commented 7 years ago

Thanks.

Rambalac · Answer 1 · Fri Apr 07 2017 03:32:55 GMT+0800 (China Standard Time)

Just was able to catch exception while closing my app

 	Rssdp.NetCore.dll!Rssdp.Infrastructure.SsdpCommunicationsServer.SendMessage(byte[] messageData, Rssdp.Infrastructure.UdpEndPoint destination)	Unknown
 	Rssdp.NetCore.dll!Rssdp.Infrastructure.SsdpDeviceLocatorBase.BroadcastDiscoverMessage(string serviceType, System.TimeSpan mxValue)	Unknown
 	Rssdp.NetCore.dll!Rssdp.Infrastructure.SsdpDeviceLocatorBase.SearchAsync(string searchTarget, System.TimeSpan searchWaitTime)	Unknown
 	System.Private.CoreLib.ni.dll!System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<Rssdp.Infrastructure.SsdpDeviceLocatorBase.<SearchAsync>d__18>(ref Rssdp.Infrastructure.SsdpDeviceLocatorBase.<SearchAsync>d__18 stateMachine)	Unknown
 	Rssdp.NetCore.dll!Rssdp.Infrastructure.SsdpDeviceLocatorBase.SearchAsync(string searchTarget, System.TimeSpan searchWaitTime)	Unknown
 	Rssdp.NetCore.dll!Rssdp.Infrastructure.SsdpDeviceLocatorBase.SearchAsync()	Unknown

Troy Willmot · Answer 2 · Sat Apr 08 2017 12:43:11 GMT+0800 (China Standard Time)

If this happens while closing the app, it's not exactly random as the title suggests.

You've started an async task that is sending messages, and then you close the app while the send is in progress. Closing the app disposes the socket, which causes the socket calls on the other thread to throw a disposed exception.

When I get time I'll update the search code to suppress that exception in the right circumstances, but really if you're going to allow closing your app while async jobs like this are in progress (in RSSDP or anything else) you should be prepared to handle the exceptions in you app code.

Troy Willmot · Answer 3 · Sat Apr 08 2017 12:50:12 GMT+0800 (China Standard Time)

Interestingly you seem to have two different errors. In the case of the first one, the stack trace doesn't appear to show any of my code in it, so it seems to be an exception thrown in the UWP runtime. It also appears to be happening on an internal thread, again with none of my code in the call stack, so I'm not sure what I can do about that. I can't even catch and suppress the error, since I have no code at the top of the call stack in which to put the try. It appears the socket is in a listening state and is throwing the error if the socket gets closed/disposed, but it shouldn't (you obviously need to be able to close a socket in that state at some point). I'm not sure at this stage how I can avoid that. Interestingly I haven't seen this error myself, despite having two LOB UWP apps that use the library. I'm not sure why you see it and I don't. Does it happen consistently? Is it when you close the app?

The second exception it should be possible to handle.

Troy Willmot · Answer 4 · Sun Apr 23 2017 09:44:07 GMT+0800 (China Standard Time)

Hi,
I am still unable to reproduce the first error mentioned. Do you have any answers to my questions? Can you provide a project that reliable reproduces the issue?
Thanks.

Troy Willmot · Answer 5 · Sun Apr 23 2017 09:58:23 GMT+0800 (China Standard Time)

For the second error I've decided this is not a bug and I am not going to change the code at this time;

Disposing the locator while a search is in progress is a potential bug (or bad design) in the client app. If I were to change the code so it did not throw (and returned either a partial or empty result set) then the other thread in the app may error in some other way that makes it harder to understand what the problem is. The ObjectDisposedException can be caught and handled/suppressed by the client app if it knows this isn't a problem (and it also then knows not to the use the result)
There is actually a unit test in the library that checks that we throw ObjectDisposedException (instead of some other exception such as null reference etc) when this case happens. This serves as documentation that it is the expected behaviour.
Changing this is a breaking change - there may be existing applications that rely on ObjectDisposedException being thrown in this case, and removing that may break those applications.

I suggest, for the second case, you catch and handle/suppress the exception in your own code and take whatever action is appropriate (probably doing nothing and allowing the thread to end).

The first exception raised is still something I would like to fix, but as mentioend previously, I cannot reproduce and cannot see how to fix.

Troy Willmot · Answer 6 · Wed May 10 2017 14:57:21 GMT+0800 (China Standard Time)

Hi,
Any update or project to reproduce the first issue?
I have a couple of different UWP Win10 projects and haven't been able to reproduce, so any more info or a project that reproduces the issue (or steps to reproduce) would be useful.
Thanks.

Rambalac · Answer 7 · Fri May 12 2017 11:08:48 GMT+0800 (China Standard Time)

Sorry, but I don't have statistic on that error anymore. I got it from app users and then I just added it to unhandled exception handler. I still get it sometimes on my local device but that's not so often. I tried to reproduce it that weeks but did not get it in debugger.

Troy Willmot · Answer 8 · Tue May 16 2017 14:23:52 GMT+0800 (China Standard Time)

I think I may have fixed this in v3.5.3. I believe the stacktrace refers to a compiler generated method that is a lambda function used as part of a task continuation. I've added code/logic there to avoid disposed exception caused by the locator class itself being disposed, so I hope that will fix this. Since neither of us can reproduce at will, we can't really confirm either way so I'm going to close this issue. If the issue continues to occur after upgrading to 3.5.3, please let me know. Thanks.