Re: [xml] Global error (xmlLastError) not cleaned up if xmlCleanupParser() is called on a different thread!

[Martin Ba <0xcdcdcdcd gmx at>]

On 09.06.2014 16:19, Daniel Veillard wrote:
> On Thu, Apr 10, 2014 at 01:27:30PM +0200, Martin Ba wrote:
> > Hi all!
> >
> > It would appear that when you have a scenario like this
> >
> > + + + +
> > // Thread 1:
> > xmlInitParser();
> > // ...
> > // anything that sets the last error, e.g.:
> > xmlReadFile("file isn't there", NULL, XML_PARSE_NOBLANKS);    
> >
> > // Thread 2:
> > xmlCleanupParser();
> > + + + +
> >
> > even if (in Thread_2) you correctly call xmlCleanupParser() (once) at the
> > very end and don't do anything with libxml2 afterwards, the global error
> > will be leaked.
> >
> > (I also tried with the latest Windows binaries I could find -- 2.9.1 -- same
> > problem.)
> >
> > Is this a known problem? Any fix for this?
> >
> > Note the workaround for me is to call xmlResetLastError() after processing
> > any error received from libxml, in which case the global last error is
> > immediately cleaned up.
> >
> >
> > cheers,
> > Martin
> >
> > p.s.: Why would anyone do this?:
> > * Once scenario is when DLL's are loaded/unloaded dynamically.
> > * Where I actually hit this is we have a .NET/C# application that loads a
> > C++ module that contains a global initialization object for libxml2 that
> > does init and cleanup. In a managed application, destructors of global
> > objects are not necessarily executed on the same thread as their
> > constructors.
>
>    Yes that's a known limitation, and why I suggest to run
> xmlInitParser() in the main thread. Also note of the danger of running
> xmlCleanupParser() on unloading, as some of the libraries you linked to
> (possibly indirectly)  could also run libxml2. So something to do only
> in a very controlled context, i have had the case of extension mechanism
> are being used, and then those use libxml2 in turn and havoc follows.
>    If I were redoing libxml2 now (or had been in last 10 years) there
> would be no global state, but with the API as-is and the need to keep
> ABI we are stuck with it :-\ mistake done back in 98 ....


Thanks for this info. At least I now know that there isn't much I can do 
with the current version.

I would like to note a few points:

* In this case, running xmlInitParser() on the main thread doesn't help 
-- in fact it *is* run on the main thread -- the problem is that 
unloading potentially happens on a different thread when loaded into a 
.NET process.
* Yes, the global Init/Cleanup is a problem, I understand.
* I would like to observe that -- for those Windows applications I 
maintain and know -- ABI compatibility is a non-issue, as the 
libxml2.dll is part of the app distribution anyway.
* For this specific case (error cleanup), I strongly believe that the 
problem could be corrected without affecting either the API or ABI, but 
I don't have time to investigate more since the workaround 
`xmlResetLastError` does work OK for me, as I only make libxml2 calls 
from C++ wrappers anyway.

Thanks,
Martin