Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.
El dj 17 de 08 del 2006 a les 11:04 -0500, en/na Brian Crowell va escriure: Robert Jordan wrote: This is related to this bugfix: http://bugzilla.ximian.com/show_bug.cgi?id=76757 http://bugzilla.ximian.com/showattachment.cgi?attach_id=17200 You guys might want to look at the part of this patch that applies to the class libraries, as I found some really silly things going on in there. They are not so silly. The problem is we can't leak objects created in one domain to another domain. That's why CADMessageBase makes a copy of the content of the CADObjRef, instead of reusing it. Lluis. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.
Lluis Sanchez wrote: They are not so silly. The problem is we can't leak objects created in one domain to another domain. That's why CADMessageBase makes a copy of the content of the CADObjRef, instead of reusing it. The copies are made in CADMessageBase.UnmarshalArgument, which, if I'm not mistaken, is called after the jump to the new domain. That means that the contents of CADObjRef have already been serialized and deserialized, so no copy needs to be made-- the contents have already been copied. The silly thing about it to me is that ObjRef is marked ISerializable. In other words, it knows how to serialize itself. CADObjRef takes advantage of this by storing the ObjRef in a field-- but once it's across the gap, it discards most of the ObjRef's internal information by only reporting the TypeName string on the other side. Think about that-- the ObjRef's TypeInfo instance is serialized and deserialized, and then the type's name is pulled from this field to construct yet *another* TypeInfo instance from the *less* applicable type data at the far end of the channel. That's why I changed the code to preserve the work the ObjRef had done in serializing itself, and used the CADObjRef type to preserve the only piece of information that the ObjRef is missing: the domain ID, needed to construct a path back to the object underlying the ObjRef. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.
Ok, most of problems seems to be solved thanks to Miguel BUT when i've seen the changelog : * image.c (full_path): A new method used to obtain the actual path of an assembly even in the presence of symbolic links. This is necessary for the case where we are running a binary that has been GACed, but we are using the published path name ($prefix/mono/1.0/blah.exe) which happens to point to the real file in the GAC. This was the source of the failure for the `xsp' command with the recent AppDomain changes, as far as the runtime was concerned, there were two different assemblies: $prefix/mono/1.0/blah.exe and $prefix/mono/gac/blah/version/blah.exe. and this cause many problems with my applications... Because many of them use the same libraries and I use symbolic links in the /bin directory to share them... I don't want to use the Gac because many of them are not strong signed! Now i've this error when I launch my application : Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error. Error message: (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.Shared.v6.1.dll' (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll' In fact there's a symbolic link /home/hubert/applications/IntranetAdmin/bin/Infragistics.WebUI.Shared.v6.1.dll that point to /home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll !!! It used to work well... Symbolic link are an important feature of UNIX Le jeudi 17 aot 2006 11:04 -0500, Brian Crowell a crit : Robert Jordan wrote: This is related to this bugfix: http://bugzilla.ximian.com/show_bug.cgi?id=76757 http://bugzilla.ximian.com/showattachment.cgi?attach_id=17200 You guys might want to look at the part of this patch that applies to the class libraries, as I found some really silly things going on in there. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.
On Fri, 2006-08-18 at 10:21 +0200, Hubert FONGARNAND wrote: Ok, most of problems seems to be solved thanks to Miguel [...] Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error. Error message: (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.Shared.v6.1.dll' (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll' In fact there's a symbolic link /home/hubert/applications/IntranetAdmin/bin/Infragistics.WebUI.Shared.v6.1.dll that point to /home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll !!! This is now fixed in svn. Well, it's more of a workaround for the weekend, as on Monday we'll do the real fix. Thanks for testing. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] XSP Problem : System.Exception: Error reading headers.
I've updated mono today from svn... XSP was totally broken (deadlock when requesting a page), so i've updated xsp too Now it works partially because, i get this error when i do a postback. System.Exception: Error reading headers. Server stack trace: at Mono.WebServer.XSPWorkerRequest.GetRequestHeaders () [0x0] at Mono.WebServer.XSPWorkerRequest..ctor (Int32 requestId, Mono.WebServer.XSPRequestBroker requestBroker, IApplicationHost appHost, System.Net.EndPoint localEP, System.Net.EndPoint remoteEP, System.String verb, System.String path, System.String queryString, System.String protocol, System.Byte[] inputBuffer, IntPtr socket, Boolean secure) [0x0] at Mono.WebServer.XSPApplicationHost.ProcessRequest (Int32 reqId, Int64 localEPAddr, Int32 localEPPort, Int64 remoteEPAdds, Int32 remoteEPPort, System.String verb, System.String path, System.String queryString, System.String protocol, System.Byte[] inputBuffer, System.String redirect, IntPtr socket, Mono.WebServer.SslInformations ssl) [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices:InternalExecute (System.Reflection.MethodBase,object,object[],object[]) at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage (System.MarshalByRefObject target, IMethodCallMessage reqMsg) [0x0] Exception rethrown at [0]: --- System.Runtime.Remoting.RemotingException: Method 'Read' not found in type 'Mono.WebServer.BaseRequestBroker' Server stack trace: at System.Runtime.Remoting.Messaging.CADMethodCallMessage.GetMethod () [0x0] at System.Runtime.Remoting.Messaging.MethodCall..ctor (System.Runtime.Remoting.Messaging.CADMethodCallMessage msg) [0x0] at System.AppDomain.ProcessMessageInDomain (System.Byte[] arrRequest, System.Runtime.Remoting.Messaging.CADMethodCallMessage cadMsg, System.Byte[] arrResponse, System.Runtime.Remoting.Messaging.CADMethodReturnMessage cadMrm) [0x0] at (wrapper remoting-invoke-with-check) System.AppDomain:ProcessMessageInDomain (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage) at System.Runtime.Remoting.Channels.CrossAppDomainSink.ProcessMessageInDomain (System.Byte[] arrRequest, System.Runtime.Remoting.Messaging.CADMethodCallMessage cadMsg) [0x0] Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] --- End of inner exception stack trace --- at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] I think there's a problem in the runtime! Thanks hubert ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.
Robert Jordan wrote: This is related to this bugfix: http://bugzilla.ximian.com/show_bug.cgi?id=76757 http://bugzilla.ximian.com/showattachment.cgi?attach_id=17200 You guys might want to look at the part of this patch that applies to the class libraries, as I found some really silly things going on in there. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
