Re: [Mono-dev] MonoMethod-MethodInfo
That is totally acceptable. Anyone with an idea where the Module identifier sits on monoclass? On Sun, Feb 15, 2015 at 10:52 AM, Konrad Kruczynski kkruczyn...@antmicro.com wrote: Note however, that resolution via metadata token can only give you an open type, that is information about bound generic type is lost during MethodInfo - MetadataToken - MethodInfo (since, naturally, only open types are present in the assembly). -- BR, Konrad 2015-02-15 9:15 GMT+01:00 Greg Young gregoryyou...@gmail.com: Now to get module on the unmanaged side. I figured it might be in MonoClass but have yet to find it there. Maybe I should be looking under the referenced MonoImage (though that doesn't seem quite right) On Sun, Feb 15, 2015 at 9:00 AM, Jeroen Frijters jer...@sumatra.nl wrote: If you know the module on the managed side, Module.ResolveMethod() can be used to get a MethodInfo from a token. Regards, Jeroen -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Greg Young Sent: Saturday, February 14, 2015 21:56 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] MonoMethod-MethodInfo Let's say I have a MonoMethod in unmanaged code. I want to pass some data out of that code back into managed code (using some identifiers of the monomethod) so that the managed code can obtain a MethodInfo via reflection. At first I thought about passing the token(s). I cannot however find anyway of looking up a MethodInfo based on its token (nor a type ...). I could get the type and then iterate over the methods but this seems like a bad idea. 1) Am I missing something with tokens on the managed side? 2) Is there some other way of doing this that I am missing? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoMethod-MethodInfo
Note however, that resolution via metadata token can only give you an open type, that is information about bound generic type is lost during MethodInfo - MetadataToken - MethodInfo (since, naturally, only open types are present in the assembly). -- BR, Konrad 2015-02-15 9:15 GMT+01:00 Greg Young gregoryyou...@gmail.com: Now to get module on the unmanaged side. I figured it might be in MonoClass but have yet to find it there. Maybe I should be looking under the referenced MonoImage (though that doesn't seem quite right) On Sun, Feb 15, 2015 at 9:00 AM, Jeroen Frijters jer...@sumatra.nl wrote: If you know the module on the managed side, Module.ResolveMethod() can be used to get a MethodInfo from a token. Regards, Jeroen -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Greg Young Sent: Saturday, February 14, 2015 21:56 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] MonoMethod-MethodInfo Let's say I have a MonoMethod in unmanaged code. I want to pass some data out of that code back into managed code (using some identifiers of the monomethod) so that the managed code can obtain a MethodInfo via reflection. At first I thought about passing the token(s). I cannot however find anyway of looking up a MethodInfo based on its token (nor a type ...). I could get the type and then iterate over the methods but this seems like a bad idea. 1) Am I missing something with tokens on the managed side? 2) Is there some other way of doing this that I am missing? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test ___ 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
Re: [Mono-dev] WCF WebServiceHost crashes mono if client disconnects early
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 alexhg...@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) [0x0] 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) [0x0] 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) [0xb] 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) [0x0] 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
Re: [Mono-dev] MonoMethod-MethodInfo
Now to get module on the unmanaged side. I figured it might be in MonoClass but have yet to find it there. Maybe I should be looking under the referenced MonoImage (though that doesn't seem quite right) On Sun, Feb 15, 2015 at 9:00 AM, Jeroen Frijters jer...@sumatra.nl wrote: If you know the module on the managed side, Module.ResolveMethod() can be used to get a MethodInfo from a token. Regards, Jeroen -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Greg Young Sent: Saturday, February 14, 2015 21:56 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] MonoMethod-MethodInfo Let's say I have a MonoMethod in unmanaged code. I want to pass some data out of that code back into managed code (using some identifiers of the monomethod) so that the managed code can obtain a MethodInfo via reflection. At first I thought about passing the token(s). I cannot however find anyway of looking up a MethodInfo based on its token (nor a type ...). I could get the type and then iterate over the methods but this seems like a bad idea. 1) Am I missing something with tokens on the managed side? 2) Is there some other way of doing this that I am missing? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF WebServiceHost crashes mono if client disconnects early
As far as I can tell, that patch fixes the crash. I'll be doing some more testing in the next few days. I'd be grateful if you could also have a look at https://bugzilla.xamarin.com/show_bug.cgi?id=20764 While it's not a crashing bug, it causes any OperationContract with a return type of void to return status code 500 Internal Server Error, which can cause undesirable effects in client applications. The proposed patch would work, though I'm not sure if it's the right way to do it. Thanks, Alex On Sun, Feb 15, 2015 at 3:38 PM, Miguel de Icaza mig...@xamarin.com 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 alexhg...@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) [0x0] 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) [0x0] 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) [0xb] 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
Re: [Mono-dev] WCF WebServiceHost crashes mono if client disconnects early
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 alexhg...@gmail.com mailto:alexhg...@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) [0x0] 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) [0x0] 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) [0xb] 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
