Re: [xml] initialization issues in libxml2



Daniel,

I was not aware of this requirement on libxml2 thread safety.

In Solaris, libraries mediating access to global data use static
initializers for the library-specific synchronization objects.  This
allows use of the library by multiple other libraries without requiring
application knowledge of the lower-level library.  For instance, in our
daemon, libxml2 is a third-level library being used to read
configuration information for a second-level library.  The application
is using a thread-safe first level library, and is unaware of the
second level-library or libxml2.  Likewise, the first-level library is
unaware of the the second-level library's use of libxml2.  For
applications using multiple libraries, each of which might be invoking
libxml2 for configuration unbeknownst to the application, there is no
obvious location for the preliminary call to xmlInitParser().

While I would urge you to relax this limitation on libxml2's thread
safety, I don't really know how feasible that would be for other
(non-pthread) threading models.  For our immediate needs for libxml2 in
Solaris, I expect we can provide a .init section invoking
xmlInitParser() and discourage the use of xmlCleanupParser() in
libraries and multi-threaded applications.

                                        Thanks  -JZ

From veillard redhat com Tue May 20 00:36:54 2008

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/




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