[Zlib-devel] zlib 1.2.3.5 available for testing

[Mark Brown]

On Thu, Jan 14, 2010 at 09:56:29PM +0000, Mark Brown wrote:

> Just a heads up since I won't have time to actually debug this until the
> weekend but I'm seeing some segfaults when testing with this new version
> which appear to be down to an interaction with libxml.  Prior versions
> are fine.  Like I say, I'll debug at the weekend so libxml may not be
> the issue here but it's looking like a common theme.

OK, I think I figured out the problem here.  Unfortunately I don't see
an immediate fix that isn't terribly invasive.  What's happening is that
libxml is assuming that gzio will do a first buffer read immediately on
opening the file.  __xmlParserInputBufferCreateFilename() contains
the following code:

            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;
                    else
                        ret->compressed = 1;
                    gzrewind(context);
                }

where context boils down to a gzFile.  The big incompatibility issue
with the new code here is that it's assuming that (as used to be the
case) the first member of the gzFile is the stream.  This is rather
naughty since gzFile is an opaque type, but obviously libxml is a widely
deployed library on Linux distributions so this is a bit of an issue.

The code also appears to be assuming that gzopen() does an initial read
from the file (this is in the open path and I can't find any following
code which does the same check).

With my distro maintainer hat on this is fairly painful; I suspect one
thing we'll want here will be to keep on building the OLD_GZIO code for
ever more, providing the old versions with the existing symbol version
and defining the new gzio implementation with new symbol versions so
that old binary code continues to work.  This is not going to help on
platforms which don't have symbol versions or if code which does this
sort of thing is rebuilt, though.

Since this is all peering into implementation details that aren't even
in the header file I can't see anything zlib can do to catch this at
build time.

I've contacted the libxml maintainer in Debian about this.