2012.09.22 18:36 "[Tiff] Libtiff 3.9.7 released", by Bob Friesenhahn

2012.10.18 08:09 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Henk Jan Priester

On 10/17/2012 PM, Bob Friesenhahn wrote: 08:46

> On Wed, 17 Oct 2012, Henk Jan Priester wrote:

>> I also get the error on Linux but there it does not crash. it seems that using zlib 1.2.7 for libtiff 4.0.3 is not a good idea. not calling the error function if stream.msg = NULL the output libtiff looks oke. >> so >> When >> of


> From my experience, installing a shared library for zlib 1.2.7 is just > plain dangerous because the shared library versioning claims to be

> upward compatible with earlier versions. From what I observed, > applications which previously used the one provided with the OS

> started using my zlib 1.2.7 and became very unstable and crashed. It > did not take long for me to realize the problem and remove my version

> of the library. If I did not remove the library it is likely that a > GUI login to the system would have failed.

> I had to make changes in GraphicsMagick for 1.2.7 because the zlib

> stream interface changed its handle definition from a plain 'int' to > something else (I think an opaque structure pointer).

> Bob

I have compiled and linked the program with the static version of zlib 1.2.7 and the problem is the same.

The inflateInit function returns an error and the stream.msg = NULL.

Looking in the zlib code then in case of an error it is very likely that

stream.msg = NULL

In the start of the inflateInit routine that are several test and stream.msg is NOT set.

if (version == Z_NULL || version[0] != ZLIB_VERSION[0] || stream_size != (int)(sizeof(z_stream)))

if (strm == Z_NULL) return Z_STREAM_ERROR;

An improvement for libtiff could be that the to test at sp->stream.msg != NULL before calling


In my case the problem was caused by the 'zlib configure --solo' which results in the Z_STREAM error from inflateInit. After not using --solo it worked again.

Thanks for the feedback