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).
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 != ZLIB_VERSION || 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