ImageMagick 6.8.8-9 testsuite crash due to TIFFIgnoreTags()

[NullNix]

In 6.8.8-9 (acquired from the Debian git mirror, because as it has for weeks ImageMagick SVN is still throwing errors and refusing to let me update: my apologies if this is fixed in a later release), with libtiff 4.0.3 (but it would happen with 3.9.5 as well), we see a bunch of crashes in the testsuite, all with the same cause:

#0 0x00007f0924160455 in raise () from /lib/libc.so.6
#1 0x00007f09241635e8 in __GI_abort () at abort.c:89
#2 0x00007f0924e45571 in MagickSignalHandler (signal_number=6) at magick/magick.c:1170
#3 <signal handler called>
#4 0x00007f0924160455 in raise () from /lib/libc.so.6
#5 0x00007f09241635e8 in __GI_abort () at abort.c:89
#6 0x00007f0924e45571 in MagickSignalHandler (signal_number=11) at magick/magick.c:1170
#7 <signal handler called>
#8 0x00007f0924d726e7 in GetImageArtifact (image=0x6, artifact=artifact@entry=0x7f0914a4cf1b "tiff:ignore-tags") at magick/artifact.c:273
#9 0x00007f0914a4678f in TIFFIgnoreTags (tiff=0x2aca6a0) at coders/tiff.c:1863
#10 TIFFTagExtender (tiff=0x2aca6a0) at coders/tiff.c:1922
#11 0x00007f09147dd879 in TIFFDefaultDirectory (tif=tif@entry=0x2aca6a0) at tif_dir.c:1308
#12 0x00007f09147e4213 in TIFFReadDirectory (tif=tif@entry=0x2aca6a0) at tif_dirread.c:3471
#13 0x00007f0914806326 in TIFFClientOpen (name=name@entry=0x7fffd81ce240 "/tmp/magick-5771IXaoiLJ1LAsg", mode=mode@entry=0x7f0914a4d109 "rb", clientdata=clientdata@entry=0x6, readproc=readproc@entry=0x7f09148125a0 <_tiffReadProc>,
writeproc=writeproc@entry=0x7f0914812590 <_tiffWriteProc>, seekproc=seekproc@entry=0x7f0914812580 <_tiffSeekProc>, closeproc=closeproc@entry=0x7f0914812570 <_tiffCloseProc>, sizeproc=sizeproc@entry=0x7f09148124b0 <_tiffSizeProc>,
mapproc=mapproc@entry=0x7f09148124f0 <_tiffMapProc>, unmapproc=unmapproc@entry=0x7f09148124a0 <_tiffUnmapProc>) at tif_open.c:466
#14 0x00007f09148126d9 in TIFFFdOpen (fd=<optimized out>, name=<optimized out>, mode=<optimized out>) at tif_unix.c:158
#15 0x00007f0914812737 in TIFFOpen (name=<optimized out>, mode=<optimized out>) at tif_unix.c:197
#16 0x00007f0914a490fa in WriteGROUP4Image (image_info=0x2bb91c0, image=0x2b98640) at coders/tiff.c:2197
#17 0x00007f0924daca0d in WriteImage (image_info=<optimized out>, image=<optimized out>) at magick/constitute.c:1181
#18 0x00007f0924d7a3fe in ImageToBlob (image_info=image_info@entry=0x2aa9750, image=image@entry=0x2b98640, length=length@entry=0x7fffd81d2368, exception=exception@entry=0x2ac5e98) at magick/blob.c:1550
#19 0x00007f091135196e in Huffman2DEncodeImage (image_info=<optimized out>, image=0x2ac2c20, inject_image=<optimized out>) at coders/pdf.c:959
#20 0x00007f0911357aa3 in WritePDFImage (image_info=0x2a530f0, image=0x2ac2c20) at coders/pdf.c:1628
#21 0x00007f0924dac62f in WriteImage (image_info=<optimized out>, image=<optimized out>) at magick/constitute.c:1181
#22 0x0000000000406b98 in ValidateImageFormatsInMemory (image_info=image_info@entry=0x226f3f0, reference_filename=reference_filename@entry=0x7fffd81dc6d0 "/tmp/magick-5771Z9Y7Oh3t4Ifs", output_filename=output_filename@entry=0x7fffd81db6d0 "/tmp/magick-5771CGKcdsMk43qX",
fail=fail@entry=0x7fffd81db6b8, exception=exception@entry=0x226e7d0) at tests/validate.c:1453
#23 0x00000000004063c9 in main (argc=<optimized out>, argv=<optimized out>) at tests/validate.c:2435
(gdb) frame 9
#9 0x00007f0914a4678f in TIFFIgnoreTags (tiff=0x2aca6a0) at coders/tiff.c:1863
1863 tags=GetImageArtifact(image,"tiff:ignore-tags");

This is because the recently added TIFFIgnoreTags() is assuming that the clientdata handle is a TIFF image. While this is true for images written out by WriteTIFFImage(), it is not true for writeouts triggered by the indirect WriteImage() -> WriteGROUP4Image() -> TIFFOpen() -> TIFFFdOpen() -> TIFFClientOpen() path shown above. In that case, libtiff itself specifies the clientdata, inside TIFFOpen(), and it's not a pointer, it's the fd of the tiff file. So you're trying to open an fd as if it were a pointer. This will never work.

Two possible solutions exist: avoid the use of TIFFOpen() in WriteGROUP4Image() (reading in the blob ourselves), or avoid the use of clientdata. The latter appears difficult, so I suppose the former is preferred.

[dlemstra]

Thank you for providing such a detailed report but we already found this mistake I made and fixed it 4 weeks ago. You can find the patch here: http://trac.imagemagick.org/changeset/1 ... ers/tiff.c. Checking if the read proc is 'TIFFReadBlob' will tell us if the client data is an image.

The url to our SVN repository for the latest version of ImageMagick 6 is: 'https://subversion.imagemagick.org/subv ... geMagick-6'. Maybe you are using a different url?

[NullNix]

Ah, it's fixed! I thought it might be, a testsuite failure is a bit hard to miss. But it seemed worth reporting anyway.

As for the repo, I was using

<https://www.imagemagick.org/subversion/ ... geMagick-6>

as the SVN URL, which worked for years. The URL on the ImageMagick SVN page changed, but the change was subtle enough that I didn't notice it... sigh.