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.
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
