[xml] initialization issues in libxml2
- From: John Zolnowsky x69422/408-404-5064 <John Zolnowsky sun com>
- To: xml gnome org
- Cc: john zolnowsky sun com, Wyllys Ingersoll sun com, valerie fenwick sun com, Laszlo Peter sun com
- Subject: [xml] initialization issues in libxml2
- Date: Mon, 19 May 2008 13:05:08 -0700 (PDT)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]