abrt 1.0.8 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: convert ./mail2fax_0_28809_1270566185.tif -o /dev/null component: ImageMagick executable: /usr/bin/convert kernel: 2.6.32.11-99.fc12.x86_64 package: ImageMagick-6.5.4.7-3.fc12 rating: 4 reason: Process /usr/bin/convert was killed by signal 11 (SIGSEGV) release: Fedora release 12 (Constantine)
Created attachment 407138 [details] File: backtrace
Please provide file to reproduce.
Created attachment 407502 [details] Test file which causes convert to crash run: convert test2.tif out.pdf will crash the ImageMagick. Gimp fails to open this image, show the following message: "Depreciated and troublesome old-style JPEG compression mode, please convert to new-style JPEG compression and notify vendor of writing software" Though Evince, gThumb and Eye of Gnome opens it ok.
Please try this build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2160387
(In reply to comment #4) > Please try this build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2160387 I tested with tiff file attached to this bug. https://bugzilla.redhat.com/attachment.cgi?id=407502 [ngh@localhost ~]$ gdb convert GNU gdb (GDB) Fedora (7.1-18.fc13) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/convert...Reading symbols from /usr/lib/debug/usr/bin/convert.debug...done. done. (gdb) set args test.tif out.pdf (gdb) run Starting program: /usr/bin/convert test.tif out.pdf [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff71ec56b in putcontig8bitYCbCr22tile (img=0x7fffffff65e0, cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, fromskew=-119220, toskew=<value optimized out>, pp=<value optimized out>) at tif_getimage.c:1857 1857 YCbCrtoRGB(cp[0], pp[0]); (gdb) backtrace #0 0x00007ffff71ec56b in putcontig8bitYCbCr22tile (img=0x7fffffff65e0, cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, fromskew=-119220, toskew=<value optimized out>, pp=<value optimized out>) at tif_getimage.c:1857 #1 0x00007ffff71ee368 in gtStripContig (img=0x7fffffff65e0, raster=<value optimized out>, w=<value optimized out>, h=2338) at tif_getimage.c:840 #2 0x00007ffff71f0841 in TIFFReadRGBAImageOriented (tif=0x638c50, rwidth=1653, rheight=<value optimized out>, raster=0x7fffed0d3010, orientation=4, stop=<value optimized out>) at tif_getimage.c:480 #3 0x00007fffedf99df2 in ReadTIFFImage (image_info=0x60d800, exception=0x604c00) at coders/tiff.c:1533 #4 0x00007ffff79fb9d6 in ReadImage (image_info=<value optimized out>, exception=0x604c00) at magick/constitute.c:579 #5 0x00007ffff79fbecb in ReadImages (image_info=0x609600, exception=0x604c00) at magick/constitute.c:868 #6 0x00007ffff76ad6eb in ConvertImageCommand (image_info=0x609600, argc=3, argv=0x6028d0, metadata=0x0, exception=0x604c00) at wand/convert.c:581 #7 0x00007ffff771dc4d in MagickCommandGenesis (image_info=0x605400, command=0x4007f8 <ConvertImageCommand@plt>, argc=3, argv=0x7fffffffe348, metadata=<value optimized out>, exception=0x604c00) at wand/mogrify.c:165 #8 0x0000000000400975 in main (argc=3, argv=0x7fffffffe348) at utilities/convert.c:80
I fill it upstream: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=16155
Please see, ImageMajick team sai it is libtiff issue: http://www.imagemagick.org/discourse-server/viewtopic.php?p=58463#p58463 Reopen, reassign.
As of libtiff 3.9.2-3, the test image causes rgb2ycbcr to crash with what seems to be the same issue: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7d9b53b in putcontig8bitYCbCr22tile (img=0x7fffffffd980, cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, fromskew=0, toskew=<value optimized out>, pp=0x7ffff68e3372 "\b") at tif_getimage.c:1857 1857 YCbCrtoRGB(cp[0], pp[0]); (gdb) bt #0 0x00007ffff7d9b53b in putcontig8bitYCbCr22tile (img=0x7fffffffd980, cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, fromskew=0, toskew=<value optimized out>, pp=0x7ffff68e3372 "\b") at tif_getimage.c:1857 #1 0x00007ffff7d9d338 in gtStripContig (img=0x7fffffffd980, raster=<value optimized out>, w=<value optimized out>, h=2338) at tif_getimage.c:840 #2 0x00007ffff7d9f7c1 in TIFFReadRGBAImageOriented (tif=0x604570, rwidth=1653, rheight=<value optimized out>, raster=0x7ffff6e6b010, orientation=4, stop=<value optimized out>) at tif_getimage.c:480 #3 0x00000000004011e3 in tiffcvt (in=0x604570, out=<value optimized out>) at rgb2ycbcr.c:307 #4 0x0000000000401b3b in main (argc=2, argv=0x7fffffffe828) at rgb2ycbcr.c:121 So indeed it's not ImageMagick's fault. Also, tiff2rgba crashes, but with a different stack trace: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7d87c8b in TIFFYCbCrtoRGB (ycbcr=0x608cb0, Y=<value optimized out>, Cb=<value optimized out>, Cr=<value optimized out>, r=<value optimized out>, g=0x7fffffffe0a8, b=0x7fffffffe0a4) at tif_color.c:192 192 *b = ycbcr->clamptab[ycbcr->Y_tab[Y] + ycbcr->Cb_b_tab[Cb]]; (gdb) bt #0 0x00007ffff7d87c8b in TIFFYCbCrtoRGB (ycbcr=0x608cb0, Y=<value optimized out>, Cb=<value optimized out>, Cr=<value optimized out>, r=<value optimized out>, g=0x7fffffffe0a8, b=0x7fffffffe0a4) at tif_color.c:192 #1 0x00007ffff7d9b51a in putcontig8bitYCbCr22tile (img=0x7fffffffe1c0, cp=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, fromskew=0, toskew=<value optimized out>, pp=0x7ffff68e2010 "\33Qo\\~\200Rbrr~\200_j\254\374~\200s\204\377\374~\200\221\223\374\377~\200\224\223\377\375~\200\225\230\375\377~\200\231\230\377\376~\200\231\232\376\377~\200\233\234\377\377~\200\235\237\377\377~\200\240\240\377\377~\200\243\243\376\376~\200\243\243\376\376~\200\243\244\376\377~\200\245\246\377\377~\200\241\240\377\377~\200\235\231\377\376~\200\227\226\376\377~\200\225\225\377\377~\200\212\212\377\377~\200\214\214\377\377~\200\214\214\377\377~\200\212\212\377\377~\200\203\203\376\377~\202\203\202\377\376~\202\203\204\376\377~\202\204\202\377\375~\202{|\376\376~\202~\200\377\377~\202\200\200\377\377~\202\200\177\377\377~\202\201\200\377\377~\200\200\177"...) at tif_getimage.c:1857 #2 0x00007ffff7d9d338 in gtStripContig (img=0x7fffffffe1c0, raster=<value optimized out>, w=<value optimized out>, h=2338) at tif_getimage.c:840 #3 0x00007ffff7d9f7c1 in TIFFReadRGBAImageOriented (tif=0x603940, rwidth=1653, rheight=<value optimized out>, raster=0x7ffff6e6b010, orientation=1, stop=<value optimized out>) at tif_getimage.c:480 #4 0x0000000000401839 in cvt_whole_image (out=<value optimized out>, in=<value optimized out>) at tiff2rgba.c:401 #5 tiffcvt (out=<value optimized out>, in=<value optimized out>) at tiff2rgba.c:519 #6 main (out=<value optimized out>, in=<value optimized out>) at tiff2rgba.c:115 Also of note: tiff2ps gets an assert failure: $ tiff2ps bug583081.tif >/dev/null TIFFReadDirectory: Warning, bug583081.tif: unknown field with tag 37679 (0x932f) encountered. TIFFReadDirectory: Warning, bug583081.tif: unknown field with tag 37680 (0x9330) encountered. TIFFReadDirectory: Warning, bug583081.tif: unknown field with tag 37681 (0x9331) encountered. TIFFSetField: bug583081.tif: Unknown pseudo-tag 65538. OJPEGSetupDecode: Warning, Depreciated and troublesome old-style JPEG compression mode, please convert to new-style JPEG compression and notify vendor of writing software. tiff2ps: tif_ojpeg.c:848: OJPEGPostDecode: Assertion `sp->libjpeg_session_active!=0' failed. Aborted
There are two separate bugs here: http://bugzilla.maptools.org/show_bug.cgi?id=2207 http://bugzilla.maptools.org/show_bug.cgi?id=2208
No, make that three bugs ... http://bugzilla.maptools.org/show_bug.cgi?id=2209 I don't have a fix for this one, and am not going to try very hard since it's a "safe" failure mode.
Tom, have you looked at older tiff versions wrt this issue? This seems to crash at least EL3 and EL4 64bit versions, though crashes don't seem related.
What I've been testing is builds of the older libtiff versions on my F-11 workstation, so there might be some small discrepancies from what you see on "real" EL3/4. I did not see crashes from this particular test case on the older branches, but that doesn't mean they couldn't happen given other circumstances. A large fraction of the other open libtiff bugs *do* crash the older builds for me. My feeling is that the most prudent thing to do is apply as many of the 3.9.2 fixes to the older branches as can be made to fit. In this particular case I found that the #2207 patch doesn't seem to be needed in EL4 but the #2208 one does. Didn't look at the EL3 code yet.
(In reply to comment #12) > What I've been testing is builds of the older libtiff versions on my F-11 > workstation, so there might be some small discrepancies from what you see on > "real" EL3/4. I did not see crashes from this particular test case on the > older branches, but that doesn't mean they couldn't happen given other > circumstances. I did try EL4 libtiff built on F-12 x86_64 and it does not crash on this file, while real EL4 x86_64 dies on divide by zero. It happens in TIFFVStripSize due to what seems to be a different compiler optimization wrt ycbcrsubsampling[2] array. On real EL4, values are only stored in registers, while F-12 build uses memory. TIFFGetField is called, but it does not change ycbcrsubsampling as TIFFFieldSet returns 0. Hence following code uses whatever ycbcrsubsampling was initialized with, possibly 0 that leads to SIGPIPE in TIFFroundup calls.
Even stranger on EL3 x86_64: Starting program: /usr/bin/tiff2rgba bz583081-test2.tif /dev/null bz583081-test2.tif: Warning, unknown field with tag 513 (0x201) ignored. bz583081-test2.tif: Warning, unknown field with tag 514 (0x202) ignored. bz583081-test2.tif: Warning, unknown field with tag 37679 (0x932f) ignored. bz583081-test2.tif: Warning, unknown field with tag 37680 (0x9330) ignored. bz583081-test2.tif: Warning, unknown field with tag 37681 (0x9331) ignored. TIFFSetField: bz583081-test2.tif: Unknown pseudo-tag 65538. bz583081-test2.tif: Old-style JPEG compression support is not configured. Breakpoint 3, gtStripContig (img=0x7fbfffa380, raster=0x2a95dd6010, w=1653, h=2338) at tif_getimage.c:661 661 pos = ((row + img->row_offset) % rowsperstrip) * scanline; (gdb) s 662 (*put)(img, raster+y*w, 0, y, w, nrow, fromskew, toskew, buf + pos); (gdb) print buf $28 = (u_char *) 0x2a96c95010 "" (gdb) print pos No symbol "pos" in current context. (gdb) print ((row + img->row_offset) % rowsperstrip) * scanline $29 = 0 (gdb) print buf + ( ((row + img->row_offset) % rowsperstrip) * scanline ) $30 = (u_char *) 0x2a96c95010 "" (gdb) s Breakpoint 2, putRGBcontig8bittile (img=0x7fbfffa380, cp=0x2a96c92864, x=0, y=2337, w=2338, h=2338, fromskew=1653, toskew=0, pp=0x921 <Address 0x921 out of bounds>) at tif_getimage.c:1006 1006 {
(In reply to comment #13) > It happens in TIFFVStripSize due to what seems to be a different compiler > optimization wrt ycbcrsubsampling[2] array. On real EL4, values are only > stored in registers, while F-12 build uses memory. TIFFGetField is called, but > it does not change ycbcrsubsampling as TIFFFieldSet returns 0. Hence following > code uses whatever ycbcrsubsampling was initialized with, possibly 0 that leads > to SIGPIPE in TIFFroundup calls. It seems libtiff-subsampling.patch from bug #603703 should address this issue.
Huh, I can't duplicate a crash on this file using RHEL4-U7-RC2_http-AS-x86_64 on a beaker machine. However, I do see assorted crashes on the test files of other open libtiff bugs. Your description sounds like this particular problem might be associated with a read of uninitialized memory, so maybe the lack of reproducibility isn't so surprising. With the 603703 patch and some other patches I've been working on for the other issues, I get no crashes on EL4. The EL3 case looks really odd though ... what I would expect to get is "Sorry, requested compression method is not configured" followed by exit(1), but it looks like it's trying to plow ahead anyway ...
libtiff-3.9.4-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libtiff-3.9.4-1.fc12
libtiff-3.8.2-15.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/libtiff-3.8.2-15.fc11
libtiff-3.9.4-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libtiff-3.9.4-1.fc13
libtiff-3.8.2-15.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
libtiff-3.9.4-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
libtiff-3.9.4-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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