Re: [xml] Valgrind problems with xmlParseFile

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) {   

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')

Then in your calling program put:


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.

On 8/16/2012 12:25 PM, Alex Bligh wrote:

--On 16 August 2012 12:08:03 -0700 "Eric S. Eberhard" <eric vicsmba com> wrote:

By standard distribution do you mean that other people might use your
library with other applications?

I mean our application uses libxml2 which uses libz, and needs to
run on a standard Ubuntu (as it happens) distro. So, to work around
this in the way you suggest, I'd need to compile a special libxml2
and ensure we either static linked to it, or it was in a different
place (as you suggest), build it into an appropriate .deb package,
and then I'd have to have some process for importing security
fixes, and all the other inter-release changes into that tree,
add this to our build system, unit tests etc.

Alternatively, zlib could fix their issue, which is clearly the
best route, but Daniel appears to be meeting some resistance which
doesn't totally surprise me.

Failing that, if there were a runtime tweak to disable each of the
various handlers, that would be good enough. In fact it might even
be better, as I know for certain that the one xml file this particular
thing reads is never compressed.

Eric S. Eberhard
PO Box 3661
Camp Verde, AZ  86322

928-567-3727  work                      928-301-7537  cell             (our work)     (fun pictures)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]