Re: [xml] Valgrind problems with xmlParseFile

[Daniel Veillard <veillard redhat com>]

On Thu, Aug 16, 2012 at 02:44:11PM -0700, Eric S. Eberhard wrote:
> Yes getting it fixed is best :-)  However, using your own place is
> still a good idea if your customers install anything else
> themselves.  That is really where I get bitten.  We sell to large
> companies with IT departments and they do all kinds of crazy things
> ... usually to my detriment.  I just find using my own place
> protects me better.  Separate from how you handle the zlib issue.
>
> Meanwhile a simple hack -- see xmlIO.c
>
> /**
>  * xmlGzfileMatch:
>  * @filename:  the URI for matching
>  *
>  * input from compressed file test
>  *
>  * Returns 1 if matches, 0 otherwise
>  */
> static int
> xmlGzfileMatch (const char *filename ATTRIBUTE_UNUSED) {
>     return(1);
> }
>
> Right now it always returns 1 because the data has to be read a bit
> to see if it is zlib or not.  Which is why the problem exists even
> if the file is not zlib.  If you want to disable, simply set this to
> zero.  You can do this the complete and total hack way which I use a
> lot for quick patches like this that I don't think will be
> permanent:
> static int
> xmlGzfileMatch (const char *filename ATTRIBUTE_UNUSED) {
>      char *e=getenv("SKIP_ZLIB");
>     if (e && *e == 'Y')
>         return(0);
>     return(1);
> }
>
> Then in your calling program put:
>
> putenv("SKIP_ZLIB=Y");
>
> That will do it ... remember to set to N when you are done if your
> program might want to use zlib later.
>
> I believe that will work ... I did not test it.  Daniel might know off-hand.

  yes such a trick might work, but my experience at this point is that
*any* tuning need to be handled at the parser instance level. Wheh you
build an app with libxml2 and tweak it to your own use globally, you're
getting increasingly affected by the risk that other libraries used by
your application also use libxml2 under the hood and your global switch
just break their own processing.
  So the only solution to me would be to add a parser switch disabling
compression support, I have not looked yet, this may be need some
refactoring at the xmlIO.c internal API layer unfortunately, so it's
not trivial, and probably hard to justify to just avoid a valgrind
"error" which I'm not 100% sure is actually a bug.

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/