Re: [xml] Valgrind problems with xmlParseFile

Simple option -- if you never use zlib build it without zlib ... E

On 8/16/2012 3:21 AM, Daniel Veillard wrote:
On Thu, Aug 16, 2012 at 10:52:37AM +0100, Alex Bligh wrote:
We are calling
and this is producing Valgrind errors.

On inspection, it appears to be coming from the code snippet below,
almost certainly the gzdirect call (though the name is lost from
the stack trace).

Other people have seen this outside libxml and it is probably a zlib
issue. However, we KNOW our file is not compressed. Is there a way
that we can do an xmlParseFile and say "please don't even try to
use a compression handler"?
  Well ... no ! Except by registering your own I/O functions
and feeding the parser yourself but with normal APIs I really want
transparent (de)compression, because well XML compress so well
in general that it's a shame to not do it more often :)

#ifdef HAVE_ZLIB_H
       if ((xmlInputCallbackTable[i].opencallback == xmlGzfileOpen) &&
               (strcmp(URI, "-") != 0)) {
#if defined(ZLIB_VERNUM) && ZLIB_VERNUM >= 0x1230
           ret->compressed = !gzdirect(context);
           if (((z_stream *)context)->avail_in > 4) {
               char *cptr, buff4[4];
               cptr = (char *) ((z_stream *)context)->next_in;
               if (gzread(context, buff4, 4) == 4) {
                   if (strncmp(buff4, cptr, 4) == 0)
                       ret->compressed = 0;
                       ret->compressed = 1;
  The problem is that if I were to avoid using the autodetection
from zlib, I would have to try to embbed some autodetection in libxml2
and that sounds just the wrong thing to do. Better fix zlib or
get valgrind updated ignore files for zlib.



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]