[Mono-dev] WCF WebServiceHost crashes mono if client disconnects early
Atsushi Eno
atsushieno at veritas-vos-liberabit.com
Mon Feb 16 06:28:22 UTC 2015
Console output for debugging is done in very limited, IIRC in only one
or two [*1] locations and not supposed to be done everywhere. They
should be actually replaced by something like WCF logging feature that
can be enabled by some configuration. IIRC it partly works. Nothing will
be logged by default and people won't notice they can log things though.
Atsushi Eno
On 2015年02月15日 22:38, Miguel de Icaza wrote:
> Hello, [ I am CCing Atsushi so he can eyeball the patch ]
>
> Thanks for the background research and for pointing me to that
> long-standing bug.
>
> It seems like a pull request was created, but that the author closed
> the pull request.
>
> I have updated the patch, can you try this and report back?
>
> https://gist.github.com/migueldeicaza/01aaf064b1bf626f8cc0
>
> Atsushi, does the above look correct? And is Console.WriteLine the
> right thing to do there, or should we use some other mechanism?
>
> Miguel
>
> On Sat, Feb 14, 2015 at 6:24 PM, Horst Müller <alexhgrep at gmail.com
> <mailto:alexhgrep at gmail.com>> wrote:
>
> Greetings!
>
> I've stumbled upon what I believe to be a rather serious problem
> in mono's WCF implementation.
>
> When a client disconnects during a transmission from a
> WebServiceHost, an exception is thrown:
>
> Exception Write failure at
> System.Net.Sockets.NetworkStream.Write (System.Byte[] buffer,
> Int32 offset, Int32 size) [0x0008e] in
> /build/mono/src/mono-3.12.0/mcs/class/System/System.Net.Sockets/NetworkStream.cs:418
>
> at System.Net.ResponseStream.InternalWrite (System.Byte[]
> buffer, Int32 offset, Int32 count) [0x00029] in
> /build/mono/src/mono-3.12.0/mcs/class/System/System.Net/ResponseStream.cs:132
>
> at System.Net.ResponseStream.Write (System.Byte[] buffer,
> Int32 offset, Int32 count) [0x000dd] in
> /build/mono/src/mono-3.12.0/mcs/class/System/System.Net/ResponseStream.cs:165
>
> at
> System.ServiceModel.Channels.Http.HttpRequestContext.InternalReply
> (System.ServiceModel.Channels.Message msg, TimeSpan timeout)
> [0x00157] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:160
>
> at
> System.ServiceModel.Channels.Http.HttpRequestContext.Reply
> (System.ServiceModel.Channels.Message msg, TimeSpan timeout)
> [0x00000] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:101
>
> at
> System.ServiceModel.Dispatcher.MessageProcessingContext.Reply
> (Boolean useTimeout) [0x00026] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/MessageProcessingContext.cs:96
>
> at
> System.ServiceModel.Dispatcher.OperationInvokerHandler.Reply
> (System.ServiceModel.Dispatcher.MessageProcessingContext mrc,
> Boolean useTimeout) [0x0001d] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/OperationInvokerHandler.cs:69
>
> at
> System.ServiceModel.Dispatcher.OperationInvokerHandler.ProcessRequest
> (System.ServiceModel.Dispatcher.MessageProcessingContext mrc)
> [0x00044] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/OperationInvokerHandler.cs:29
>
> at
> System.ServiceModel.Dispatcher.BaseRequestProcessorHandler.ProcessRequestChain
> (System.ServiceModel.Dispatcher.MessageProcessingContext mrc)
> [0x00000] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessorHandler.cs:15
>
> at
> System.ServiceModel.Dispatcher.BaseRequestProcessorHandler.ProcessRequestChain
> (System.ServiceModel.Dispatcher.MessageProcessingContext mrc)
> [0x00017] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessorHandler.cs:16
>
> at
> System.ServiceModel.Dispatcher.HandlersChain.ProcessRequestChain
> (System.ServiceModel.Dispatcher.MessageProcessingContext mrc)
> [0x0000b] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessor.cs:72
>
> at
> System.ServiceModel.Dispatcher.BaseRequestProcessor.ProcessRequest
> (System.ServiceModel.Dispatcher.MessageProcessingContext mrc)
> [0x00018] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessor.cs:26
>
>
> This exception gets caught and rethrown until it ends up at
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:596,
> where ProcessErrorWithHandlers returns false and we reply to the
> RequestContext with an error message. This then generates a second
> exception that is not caught, crashing the whole program:
>
> Unhandled Exception:
> System.InvalidOperationException: Cannot be changed after
> headers are sent.
> at System.Net.HttpListenerResponse.set_ContentType
> (System.String value) [0x00027] in
> /build/mono/src/mono-3.12.0/mcs/class/System/System.Net/HttpListenerResponse.cs:110
>
> at
> System.ServiceModel.Channels.Http.HttpStandaloneResponseInfo.set_ContentType
> (System.String value) [0x00000] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpContextInfo.cs:274
>
> at
> System.ServiceModel.Channels.Http.HttpRequestContext.InternalReply
> (System.ServiceModel.Channels.Message msg, TimeSpan timeout)
> [0x00046] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:140
>
> at
> System.ServiceModel.Channels.Http.HttpRequestContext.Reply
> (System.ServiceModel.Channels.Message msg, TimeSpan timeout)
> [0x00000] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:101
>
> at
> System.ServiceModel.Channels.Http.HttpRequestContext.Reply
> (System.ServiceModel.Channels.Message msg) [0x00000] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:96
>
> at
> System.ServiceModel.Dispatcher.ListenerLoopManager.ProcessRequest
> (IReplyChannel reply,
> System.ServiceModel.Channels.RequestContext rc) [0x0003b] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:601
>
> at
> System.ServiceModel.Dispatcher.ListenerLoopManager.TryReceiveRequestDone
> (IAsyncResult result) [0x0001a] in
> /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:575
>
>
> I've attached an example that will trigger the problem if used to
> serve a large file over a network. As soon as the client cancels
> the transfer, the application will crash. In Microsoft .NET, no
> crash is observed.
>
> I would be very grateful if someone could comment on this issue.
> Apparently the problem has been reported before, but it seems no
> fix was implemented:
> https://bugzilla.xamarin.com/show_bug.cgi?id=5926
>
> Is my example doing something that you're not supposed to do? It
> seems to me that the WebServiceHost functionality is completely
> unusable with this bug.
>
> Thanks and best regards,
> Alex
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> <mailto:Mono-devel-list at lists.ximian.com>
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
More information about the Mono-devel-list
mailing list