Re: [libvirt] [PATCH] Detailed XML errors when XML is not well-formed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 30, 2008 at 03:49:17PM +0100, Richard W.M. Jones wrote:
> This patch changes the implementations lots of functions which parse
> XML documents, so that if the XML document is not well-formed then we
> get detailed error messages.
> 
> The general form of the change is:
> 
>     static void
>     catchXMLError (void *ctx, const char *msg ATTRIBUTE_UNUSED, ...)
>     {
>         // a callback which calls virDomainReportError
>     }
>     
>     virDomainDefPtr virDomainDefParseString(virConnectPtr conn,
>                                             virCapsPtr caps,
>                                             const char *xmlStr)
>     {
>         xmlParserCtxtPtr pctxt;
>     
>         pctxt = xmlNewParserCtxt ();
>         pctxt->sax->error = catchXMLError;
>     
>         xml = xmlCtxtReadDoc (pctxt, //...) etc.
> 
> There are some unavoidable shortcomings:
> 
> (1) There is no place to stash user pointers during the callback (the
> suggestively named pctxt->userData field is already used for something
> else), so we cannot pass the virConnectPtr to the error function.  As
> a result, virterror will store the error in a global variable, and
> callers will probably not be able to access it.

Yes, that makes it rather limited & not really any benefit as is.

We can get around this though with some cleverness of thread locals.
Either we can annotate a global variable with __thread, or use the
pthread_once_t/pthread_key_t to store it.

So before starting the parse, initialize these to 'empty' or some other
defined state. Do the parse, and the error handler can store the 
problems. Once finished we can read the details out (& clear any 
state to avoid mem leak) and put them into our virConnectPtr error
object. Since you're using thread locals this is all nice & safe from
race conditions with multiple parses taking place in parallel.
 
> (2) The XML parser routinely produces multiple error messages, and
> virterror throws away all but the last one.

It'd probably be more use to only report the first one, since the latter
problems may well be caused by earlier problems.

> The errors do, however, get printed to stderr.

You won't see those except with the 'test' or 'xen' drivers run 
locally. Anything going  via the daemon will be output on the
daemon's stderr (/dev/null) and not on the client.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]