Re: [xml] calling xmlCleanupParser from a library considered harmful

[Daniel Veillard <veillard redhat com>]

On Mon, Oct 01, 2012 at 05:30:37PM +0200, Michael Stahl wrote:
> hi all,
>
> authors of libraries that use libxml2 internally for whatever reason
> should take note that calling xmlCleanupParser frees various bits of
> global state and as a result makes libxml2 effectively unusable for any
> other code in the process that also happens to use libxml2, and hence
> makes your library effectively un-usable (until the offending call is
> patched out).

 yeah, it's painful, but that function is needed in some ways to
avoid what is reported as a data leak if using valgrind for example.
As you pointed out I have tried to make the documentation as explicit
as possible, but you know how much people read those ;-)

 Except doing something like introducing a call like
  xmlProgramIsAboutToExit()
and then checking that this call has been called before allowing
xmlCleanupParser() to effectively work, I don't see how to make sure
people change their code.
 Doing this would be possible, it would change the API semantic,
but would get rid of the issue. It could be made strong by requiring
a program name as an argument (and on linux we could do some checking)
but it's probably superfluous, the extra call should be sufficient.

  Opinions about this ?

> http://www.xmlsoft.org/html/libxml-parser.html#xmlCleanupParser
>
> > This function name is somewhat misleading. It does not clean up 
> > parser state, it cleans up memory allocated by the library itself.
> > It is a cleanup function for the XML library. It tries to reclaim
> > all related global memory allocated for the library processing. One
> > should call xmlCleanupParser() only when the process has finished
> > using the library [...] WARNING: if your application is
> > multithreaded or has plugin support calling this may crash the
> > application if another thread or a plugin is still using libxml2.
> > [...]
>
> please do not _ever_ call xmlCleanupParser from a library.
>
> LibreOffice has been hit for the second time[1] now by some library
> calling xmlCleanupParser; a colleague much smarter than me wasted many
> hours tracking that down as the root cause of an obscure crash involving
> CUPS and thread local storage... which finally motivated me to add this
> hack (should work on ELF platforms) so the next time the problem is
> easier to detect:
>
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=d68113f3229d0ec8c84f77dcac3b64a3fd7e03e4
>
> regards,
>  michael
>
> [1] pedantic note: technically at the first time it was OpenOffice.org

  Hum, I though the issue with the librdf had been fixed upstream
that's my recollection anyway,

Daniel

-- 
Daniel Veillard      | Open Source and Standards, Red Hat
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/