Worth noting, with Combined patch applied (or both other applied
separately), zero unit tests are failing. So apparently, it doesn't
make anything worse, at least as far as tests go.
-Rob
On 06/28/2012 08:20 AM, Rob Wilkens wrote:
>
> Either of the attached patches illustrates what i was trying to say in
> that last patch
>
> (1) attempt2.patch : This attempts to patch just the below concern,
> and is based on a guess.
> -or- (not both)
> (2) combined.patch : This combines attempt2.patch with the patch i
> sent last night since they were on the same branch.
>
> I'm not able to test these anything beyond "does it compile" because i
> don't have sample code to reproduce this with.
>
> -Rob
>
> On 06/28/2012 07:55 AM, Rob Wilkens wrote:
>> Re : The stacktrace below...
>>
>> This occurs when an exception is raised in ChannelDispatcher.cs on
>> line 601. It tries to send back an exception message to the client
>> here, i believe. But when it does that, it uses the existing
>> RequestContext.
>>
>> It's apparent that some data is apparently being sent, such as
>> headers, on the RequestContext (rc) before we get to this exception.
>>
>> If we're dealing with the case of SocketException, which caused us to
>> fail mid-send on the RequestContext, perhaps, again, we shouldn't
>> handle this like every other exception and not reply. i.e. in the
>> exception handler here, if exception is typeof(SocketException) don't
>> reply, what might be more interesting, if this is reproducable, would
>> be to - as debugging - print the exception message and/or stacktrace
>> to the screen to see what exception caused this.
>>
>> Did you file a bug report on this? The discussion on this particular
>> issue (or any particular bug) is probably better stored in the bug
>> report comments than on the whole mailing list. PLus comments like
>> the above would stay in the bug report rather than get lost in the
>> list. IF you file a bug report, post a link to the bug report in
>> this thread (the bug # should be enough).
>>
>> -Rob
>>
>>
>> On 06/27/2012 01:02 PM, shahbour wrote:
>>>
>>>
>>> Hello After more testing between Mac and Windows this is
>>> what i got Crash Windows Mac Linux Without ErroHandler No
>>> Yes Yes With ErrorHandler (return false ) No Yes Yes With
>>> ErrorHandler (return true) No No No Before i was always
>>> returning false in IErrorHandler implementation because i
>>> only implemented for logging purpose but when i return true
>>> for the HandleError , the application fire the error and log
>>> it but never crash. Now i trying to debug the application
>>> under MonoDevelop and repreduce the error, below is what i got
>>>
>>>
>>> System.InvalidOperationException: Cannot be changed
>>> after headers are sent. at
>>> System.Net.HttpListenerResponse.set_ContentType
>>> (System.String value) [0x00027] in
>>>
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System/System.Net/HttpListenerResponse.cs:107
>>> at
>>>
>>> System.ServiceModel.Channels.Http.HttpStandaloneResponseInfo.set_ContentType
>>> (System.String value) [0x00000] in
>>>
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/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
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9
>>>
>>
>>>
>>> /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
>>>
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/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
>>>
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/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
>>>
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:601
>>> at
>>>
>>> System.ServiceModel.Dispatcher.ListenerLoopManager.TryReceiveRequestDone
>>> (IAsyncResult result) [0x0001a] in
>>>
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:575
>>>
>>> Reproducing the error is very simple, just host any application
>>> under console app and in any service function put Thread.Sleep(..)
>>> to give you time to close the browser before it reply. Then call
>>> this function from any client and close it before getting the
>>> response. In my live program i don't put Thread.sleep it is only to
>>> give us time between calling the function and closing the browser.
>>> Under windows we got the bellow that don't crash the application
>>> error.Message "An operation was attempted on a nonexistent network
>>> connection" error.InnerException {"An operation was attempted on a
>>> nonexistent network connection"} System.Exception :q
>>> {System.Net.HttpListenerException} error.ErrorCode 1229 BR Shahbour
>>> ------------------------------------------------------------------------
>>> View this message in context: Re: WCF Fail with
>>> System.Net.Sockets.SocketException: Connection reset by peer
>>> <http://mono.1490590.n4.nabble.com/WCF-Fail-with-System-Net-Sockets-SocketException-Connection-reset-by-peer-tp4650173p4650210.html>
>>> Sent from the Mono - Dev mailing list archive
>>> <http://mono.1490590.n4.nabble.com/Mono-Dev-f1517221.html> at
>>> Nabble.com.
>>>
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
