AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2012.09.22 18:36 "[Tiff] Libtiff 3.9.7 released", by Bob Friesenhahn
2012.10.17 18:26 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Henk Jan Priester
2012.10.17 17:23 "[Tiff] Que: ZIPSetupDecode errorhandling", by Henk Jan Priester
2012.10.17 17:35 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Bob Friesenhahn
2012.10.17 17:54 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Henk Jan Priester
2012.10.17 18:19 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Bob Friesenhahn
2012.10.17 22:28 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Graeme Gill
2012.10.18 08:09 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Henk Jan Priester
2012.10.18 17:39 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Frank Warmerdam
2012.10.19 07:23 "Re: [Tiff] Que: ZIPSetupDecode errorhandling", by Henk Jan Priester

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)))

return Z_VERSION_ERROR;
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

TIFFErrorExt

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