Description of problem: When you run tiff2ps with quad-jpeg.tif you'll see an "double free or corruption" message. Version-Release number of selected component (if applicable): libtiff-3.8.2-9.fc8 How reproducible: Always Steps to Reproduce: 1. Go to http://www.remotesensing.org/libtiff/images.html . 2. Download the latest archive of test images ( ftp://ftp.remotesensing.org/pub/libtiff/pics-3.8.0.tar.gz ). 3. Unpack the file quad-jpeg.tif . 4. tiff2ps quad-jpeg.tif >& /dev/null *** glibc detected *** double free or corruption (!prev): 0x0000000080013e50 *** Aborted 5. echo $? 134 Actual results: tiff2ps is aborted Expected results: tiff2ps finishes successfully Additional info: libtiff-3.6.1-12.el4_7.2 on RHEL4.7 is also affected
libtiff-3.8.2-7.el5_2.2 on RHEL5.2 is also affected
AFAICT this is simply a known unsupported case. tiff2ps reads the data using TIFFReadScanline(), which is stated in its manual page to not be usable for subsampled YCbCR data, which is what this image is. It might be prudent to put a defense into TIFFReadScanline to make it report an error, instead of blindly proceeding and perhaps overrunning the caller's buffer (as indeed is happening here). It's hard to tell however whether there are any other paths that would need to be plugged similarly.
Hmm, no, that analysis is too simplistic. tiff2ps requests RGB output, so the library ought to be able to handle it. This seems to be breakage from the CHECK_JPEG_YCBCR_SUBSAMPLING kluge: that is causing JPEGPreDecode to be invoked immediately during TIFFOpen, so it sets up tif_decoderow = JPEGDecodeRaw which is the case that won't work. After that, the main program asks for RGB mode output, but this is never reflected in a change in the selected decoding routine. I tried building with --disable-check-ycbcr-subsampling, but that just moves the failure somewhere else: in this path, tif->tif_scanlinesize is calculated too soon and never updated, so JPEGDecode refuses to do anything. The whole thing seems like a mess. Going to contact upstream for advice...
RHEL-4's libtiff (3.6.1) has this issue as well.
I think that tiffcmp suffers from the same problem. $ tiffcmp -l quad-jpeg.tif quad-jpeg.tif JPEGLib: Warning, Application transferred too many scanlines. quad-jpeg.tif: EOF at scanline 0 *** glibc detected *** tiffcmp: double free or corruption (!prev): 0x085c1568 *** ======= Backtrace: ========= /lib/libc.so.6[0x990ac1] /lib/libc.so.6(cfree+0x90)[0x9940f0] /usr/lib/libtiff.so.3(_TIFFfree+0x1d)[0x6b341ad] tiffcmp[0x8049d9a] /lib/libc.so.6(__libc_start_main+0xe0)[0x93d390] tiffcmp[0x8048881] ======= Memory map: ======== 00110000-00111000 r-xp 00110000 00:00 0 [vdso] 0085f000-00880000 r-xp 00000000 fd:00 1720040 /usr/lib/libjpeg.so.62.0.0 00880000-00881000 rw-p 00020000 fd:00 1720040 /usr/lib/libjpeg.so.62.0.0 00908000-00923000 r-xp 00000000 fd:00 2195649 /lib/ld-2.7.so 00923000-00924000 r--p 0001a000 fd:00 2195649 /lib/ld-2.7.so 00924000-00925000 rw-p 0001b000 fd:00 2195649 /lib/ld-2.7.so 00927000-00a7a000 r-xp 00000000 fd:00 2195722 /lib/libc-2.7.so 00a7a000-00a7c000 r--p 00153000 fd:00 2195722 /lib/libc-2.7.so 00a7c000-00a7d000 rw-p 00155000 fd:00 2195722 /lib/libc-2.7.so 00a7d000-00a80000 rw-p 00a7d000 00:00 0 00a82000-00aa9000 r-xp 00000000 fd:00 2195834 /lib/libm-2.7.so 00aa9000-00aaa000 r--p 00026000 fd:00 2195834 /lib/libm-2.7.so 00aaa000-00aab000 rw-p 00027000 fd:00 2195834 /lib/libm-2.7.so 00acf000-00ae1000 r-xp 00000000 fd:00 2196569 /lib/libz.so.1.2.3 00ae1000-00ae2000 rw-p 00011000 fd:00 2196569 /lib/libz.so.1.2.3 069d5000-069e0000 r-xp 00000000 fd:00 2196574 /lib/libgcc_s-4.1.2-20070925.so.1 069e0000-069e1000 rw-p 0000a000 fd:00 2196574 /lib/libgcc_s-4.1.2-20070925.so.1 06b04000-06b5a000 r-xp 00000000 fd:00 1729001 /usr/lib/libtiff.so.3.8.2 06b5a000-06b5c000 rw-p 00056000 fd:00 1729001 /usr/lib/libtiff.so.3.8.2 08048000-0804b000 r-xp 00000000 fd:00 1715304 /usr/bin/tiffcmp 0804b000-0804d000 rw-p 00002000 fd:00 1715304 /usr/bin/tiffcmp 085b0000-085d1000 rw-p 085b0000 00:00 0 [heap] b7e00000-b7e21000 rw-p b7e00000 00:00 0 b7e21000-b7f00000 ---p b7e21000 00:00 0 b7f36000-b7f39000 rw-p b7f36000 00:00 0 b7f3c000-b7f3d000 rw-p b7f3c000 00:00 0 b7f3d000-b7f43000 r--s 00000000 fd:01 8905992 /home/mmalik/quad-jpeg.tif b7f43000-b7f49000 r--s 00000000 fd:01 8905992 /home/mmalik/quad-jpeg.tif bfe34000-bfe49000 rw-p bffeb000 00:00 0 [stack] Aborted $ echo $? 134 $
Yeah, it's a library problem --- it'd affect any of these programs that try to read the image data via TIFFReadScanline.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Issue also exist in libtiff-3.8.2-11.fc10
tiffcmp segfault affects all RHEL: *RHEL3* [root@ia64-3as official-test-images]# tiffcmp -l pics/quad-jpeg.tif pics/quad-jpeg.tif JPEGLib: Warning, Application transferred too many scanlines. pics/quad-jpeg.tif: EOF at scanline 0 Segmentation fault *RHEL4* [root@s390-4as-8-v1 official-test-images]# tiffcmp -l pics/quad-jpeg.tif pics/quad-jpeg.tif JPEGLib: Warning, Application transferred too many scanlines. pics/quad-jpeg.tif: EOF at scanline 0 *** glibc detected *** double free or corruption (!prev): 0x00415a18 *** Aborted *RHEL5* [root@s390x-5s-v1 official-test-images]# tiffcmp -l pics/quad-jpeg.tif pics/quad-jpeg.tif JPEGLib: Warning, Application transferred too many scanlines. pics/quad-jpeg.tif: EOF at scanline 0 *** glibc detected *** tiffcmp: double free or corruption (!prev): 0x000000008000e420 *** Aborted
Affected packages from comment #10: RHEL3 - libtiff-3.5.7-32.el3 RHEL4 - libtiff-3.6.1-12.el4_8.3 RHEL5 - libtiff-3.8.2-7.el5_3.3
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still there as of new upstream version 3.9.2 :-(
I did some digging today and determined that the tiffcmp crash arises from a set of issues that are entirely independent of those confusing tiff2ps. tiffcmp is trying to read the data without upsampling it to full size, and there are several bugs associated with that, which I have now filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=2140 The tiff2ps code wants to perform upsampling, and the bugs in that are elsewhere.
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
As of libtiff-3.9.2-3, tiff2ps seems to work correctly with quad-jpeg.tif. Also, tiffcmp doesn't crash, though it doesn't really work either; see upstream report 2140.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.