Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 4955] Capture stops when built with zlib support

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4955

--- Comment #19 from Guy Harris <guy@xxxxxxxxxxxx> 2010-09-09 11:08:29 PDT ---
In Gentoo, that change to zlib.h is

   
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/zlib/files/zlib-1.2.5-lfs-decls.patch?revision=1.3&view=markup

"http://bugs.gentoo.org/316377

try to unbreak over-eager LFS logic in zlib header"

The title of that bug is "dev-libs/libxml2-2.7.7 fails due to gzopen64'
implicitly converted to pointer w/ zlib-1.2.5".

The patch is mentioned in comment #5:

    http://bugs.gentoo.org/show_bug.cgi?id=316377#c5

which says

"I think the fix for this should go into zlib. zlib.h does a #define gzopen
gzopen64 but then conditionally declares the function (based on
_LARGEFILE64_SOURCE). The define and the declaration should be controlled by
the same condition.

Attaching a patch that does this (and fixes the problem here)."

The zlib.h code is

/* provide 64-bit offset functions if _LARGEFILE64_SOURCE defined, and/or
 * change the regular functions to 64 bits if _FILE_OFFSET_BITS is 64 (if
 * both are true, the application gets the *64 functions, and the regular
 * functions are changed to 64 bits) -- in case these are set on systems
 * without large file support, _LFS64_LARGEFILE must also be true
 */                                                                             
#if defined(_LARGEFILE64_SOURCE) && _LFS64_LARGEFILE-0
   ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
   ZEXTERN z_off64_t ZEXPORT gzseek64 OF((gzFile, z_off64_t, int));
   ZEXTERN z_off64_t ZEXPORT gztell64 OF((gzFile));
   ZEXTERN z_off64_t ZEXPORT gzoffset64 OF((gzFile));
   ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off64_t));  
   ZEXTERN uLong ZEXPORT crc32_combine64 OF((uLong, uLong, z_off64_t));
#endif

#if !defined(ZLIB_INTERNAL) && _FILE_OFFSET_BITS-0 == 64 && _LFS64_LARGEFILE-0
#  define gzopen gzopen64
#  define gzseek gzseek64
#  define gztell gztell64
#  define gzoffset gzoffset64
#  define adler32_combine adler32_combine64
#  define crc32_combine crc32_combine64
#  ifdef _LARGEFILE64_SOURCE
     ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
     ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int));  
     ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile));  
     ZEXTERN z_off_t ZEXPORT gzoffset64 OF((gzFile));
     ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off_t));
     ZEXTERN uLong ZEXPORT crc32_combine64 OF((uLong, uLong, z_off_t));
#  endif
#else
   ZEXTERN gzFile ZEXPORT gzopen OF((const char *, const char *));
   ZEXTERN z_off_t ZEXPORT gzseek OF((gzFile, z_off_t, int));
   ZEXTERN z_off_t ZEXPORT gztell OF((gzFile));
   ZEXTERN z_off_t ZEXPORT gzoffset OF((gzFile));
   ZEXTERN uLong ZEXPORT adler32_combine OF((uLong, uLong, z_off_t));
   ZEXTERN uLong ZEXPORT crc32_combine OF((uLong, uLong, z_off_t));
#endif

So, with that version, gzopen64() is declared if:

    _LFS64_LARGEFILE-0 is non-zero (i.e., _LFS64_LARGEFILE is defined and its
value is non-zero);

    _LARGEFILE64_SOURCE is defined.

With their change, it's declared if:

    _LFS64_LARGEFILE-0 is non-zero (i.e., _LFS64_LARGEFILE is defined and its
value is non-zero);

    _LARGEFILE64_SOURCE is defined *OR* (ZLIB_INTERNAL is not defined and
FILE_OFFSET_BITS-0 == 64, i.e. it's defined as 64).

I'm not sure that change makes a difference.  However, if this is a
64-bit-file-offset support issue, the difference between OS X/*BSD and
everybody else might matter here - this problem might only show up on everybody
else.  zlib has been a bit problematic in its dealing with file offsets on some
4.4-Lite-based systems in the past; see the long comment in
wiretap/file_wrappers.c.  I think they are attempting to handle large file
support a bit better, but might have broken things.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.