From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Re: [Xen-changelog] Added exception handler for ProtocolError. Date: Thu, 23 Mar 2006 10:59:03 -0600 Message-ID: <4422D3D7.4010009@us.ibm.com> References: <4422CBCA.5080204@us.ibm.com> <20060323164703.GD14259@leeni.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060323164703.GD14259@leeni.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ewan Mellor Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Ewan Mellor wrote: > On Thu, Mar 23, 2006 at 10:24:42AM -0600, Anthony Liguori wrote: > >> Hi Ewan, >> >> ProtocolError's shouldn't happen. The case where os.geteuid() != 0 is a >> possibility (although I thought we had a check earlier for that?). >> However, if we are getting them for another reason, something's wrong. >> > > I wasn't sure whether you'd get a ProtocolError or an IOError if you tried to > connect to the socket as non-root, so I just threw the geteuid test in -- if > we can confirm that it's not needed (i.e. you are guaranteed to get an > IOError) then we can do without that. > > The ProtocolErrors in general were being thrown whenever an exception made it > all the way back to the top of a function registered with the server (i.e. any > of our message handlers). Yeah, in xen.util.xmlrpclib2:TCPXMLRPCServer::_marshaled_dispatch() we should catch any exception and convert it to a proper xmlrpclib.Fault. If exceptions are getting past that, there's something wrong. I'll look at it today and see if I can't figure out what's happening. Thanks for all your effort in merging this stuff Ewan! Regards, Anthony Liguori > These exceptions would get translated to a 500 > Internal Server Error which would appear at the client as a ProtocolError. I > don't know whether it is any exception that causes this, or only ones that > inherit from StandardError or something like that. One particular trigger was > XMLRPCServer.dispatch, which wasn't checking the return value from lookup. > This caused it to try and call None as a function whenever the user specified > a domain that did not exist. > > Ewan. >