Re: [xml] correct version of libxml2

["Floodeenjr, Thomas" <thomas_floodeenjr mentor com>]

Hello,

We have an exception thrown in libxml2. The problem exists only if there are any input callbacks registered 
prior to xmlParseFile call. And this is our case. However, those input callbacks were registered by a library 
that is already unloaded and the callbacks are invalid. This is a result of xmlCleanupParser removal since 
among others xmlCleanupParser call cleans also that callbacks table.

I see there are the following functions in libxml2 interface:

void xmlCleanupInputCallbacks(void);
int xmlPopInputCallbacks(void);

These should take care of input callbacks removal only. We have just checked that if we call any of them the 
crash is gone - the input callbacks are cleared correctly.

However, the functions' descriptions are unclear to us:

Function: xmlCleanupInputCallbacks
void     xmlCleanupInputCallbacks       (void)
clears the entire input callback table. this includes the compiled-in I/O.


Function: xmlPopInputCallbacks
int      xmlPopInputCallbacks           (void)
Clear the top input callback from the input stack. this includes the compiled-in I/O.
Returns:        the number of input callback registered or -1 in case of error.

Questions/problems:

1.      What does compiled-in I/O mean in terms of input callbacks? Is it safe to clean them?
2.      Which function is better for our  multi-threaded environment - I would say the second one, but would 
like to know for sure from one of the experts...

Thanks,
-Tom

Thomas Floodeen, Jr.
Mentor Graphics BSD
720.494.1133


-----Original Message-----
From: Floodeenjr, Thomas 
Sent: Thursday, May 12, 2011 2:58 PM
To: 'veillard redhat com'
Subject: RE: correct version of libxml2
Daniel,

After having removed calls to xmlCleanupParser() to fix the crash on UNIX, we now get this exception on 
Windows while exiting our application. This leads to a crash. If we put the call back in to 
xmlCleanupParser(), the exception and crash go away.

>       libxml2.dll!__xmlParserInputBufferCreateFilename(const char * URI=0x148ef090, xmlCharEncoding 
> enc=409135704)  Line 2498 + 0x9 bytes     C
        libxml2.dll!xmlDefaultExternalEntityLoader(const char * URL=0x1862ea58, const char * ID=0x00000000, 
_xmlParserCtxt * ctxt=0x148ef090)  Line 3885 + 0x7 bytes    C
        libxml2.dll!xmlLoadExternalEntity(const char * URL=0x1862ea58, const char * ID=0x00000000, 
_xmlParserCtxt * ctxt=0x148ef090)  Line 3945 + 0x11 bytes    C
        libxml2.dll!xmlCreateURLParserCtxt(const char * filename=0x1862ea58, int options=0)  Line 13516 + 
0x17 bytes    C
        libxml2.dll!xmlParseFile(const char * filename=0x0a070418)  Line 13667 + 0x11 bytes     C

Are there situations where we do want to call xmlCleanupParser() on Windows, but not Linux/UNIX? It appears 
the code does different things on Windows than Linux/UNIX.

Thanks,
-Tom

Thomas Floodeen, Jr.
Mentor Graphics BSD
720.494.1133


-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com]
Sent: Monday, April 25, 2011 6:01 PM
To: Floodeenjr, Thomas
Cc: xml gnome org
Subject: Re: correct version of libxml2
-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com] 
Sent: Monday, April 25, 2011 6:01 PM
To: Floodeenjr, Thomas
Cc: xml gnome org
Subject: Re: correct version of libxml2

On Mon, Apr 25, 2011 at 03:02:45PM +0000, Floodeenjr, Thomas wrote:
> Daniel,
>
> Yes indeed, we seem to be calling xmlCleanupParser() in many places. 
> We will get with our engineering teams to investigate removing this 
> call from our code. I would imagine that they thought at the time that 
> this call was needed, as it appears to have had no ill side effects in 
> the 2.6.x versions of libxml2.

  Oh, that call always deallocated all global variables used by libxml2 except that some things which were 
forgotten in the past are now more throroughtly cleaned up. Things like entity definitions for predefined 
entities of XML have always been cleaned up that way for example,
  Calling it while the library or its data were still in use has always been a dangerous thing to do, then 
it's a matter of luck...

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization 
library  http://libvirt.org/