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

Re: [xml] initialization issues in libxml2



Just wanted to add that we're using 2.6.31.

Laca

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



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