Re: [xml] initialization issues in libxml2

[Daniel Veillard <veillard redhat com>]

On Tue, May 20, 2008 at 03:34:48PM +1200, Laszlo (Laca) Peter wrote:
> Just wanted to add that we're using 2.6.31.

  Have you read http://xmlsoft.org/threads.html
"call xmlInitParser() in the "main" thread before using any of the libxml2 API"

  So right, there is no protection against multiple concurrent initialization
calls. That's on purpose based on that rule and to avoid tons of troubles
at initialization time.
  If your problem still persists after the xmlInitParser() call then I'm
open to suggestions, after a clear analysis of the problem.

  thanks,

Daniel

> On Mon, 2008-05-19 at 13:05 -0700, John Zolnowsky x69422/408-404-5064
> wrote:
> > We've recently observed a daemon hung in libxml2.
> >
> > Analysis of the core file showed that multiple threads had been
> > through globals.c:xmlInitGlobals().
> >
> > I found two problems in the initialization routines of libxml2.
> >
> > 1) In globals.c, the initialization of xmlThrDefMutex is not protected
> > against multiple threads simultaneously calling
> > xmlInitializeGlobalState(), or repeatedly calling xmlInitGlobals().
> >
> > 2) In parser.c, the routine xmlInitParser() checks a static variable
> > outside any lock, performs multiple initializations, then sets the
> > static to indicate no further initializations.
> >
> > With the conversion of all Solaris libraries to default to lazyload,
> > there would be a tendency for multiple threads to be synchronized at
> > their first call to libxml2, resulting in multiple threads being able
> > to enter these initialization routines nearly simultaneously.  This
> > would cause redundant initializations, which in the case of
> > xmlInitGlobals(), would cause the creation of xmlMutex'es and trashing
> > of previous values of xmlThrDefMutex.  In the case captured in the
> > corefile, apparently thread2 locked valueA of xmlThrDefMutex, thread3
> > blocked on valueA, some other thread4 now called xmlInitGlobals()
> > creating valueB, and finally thread2 released the unowned valueB,
> > leaving thread3 hung forever.
> >
> > All initialization routines in libxml2 should be checked for inadequate
> > static guards.  Correction of these problems will require some
> > structural changes to globals.c and parser.c, similar to the code
> > wrapping xmlOnceInit() in threads.c
> >
> >                                     Thanks  -JZ
>
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/