Hide Forgot
Description of problem: if I try to process the attached file (which was provided by Thomas Pollet as cups bug reproducer, see bug #441692) using ImageMagick, it crashes Version-Release number of selected component (if applicable): Version: ImageMagick 6.3.5 09/20/07 Q16 http://www.imagemagick.org (but it crashes also the recent version) How reproducible: always Steps to Reproduce: 1. identify test.png (for example) Actual results: $ identify test.png identify: magick/blob.c:469: CloseBlob: Assertion `image->signature == 0xabacadabUL' failed. Aborted (core dumped) Expected results: it does not crash ... Additional info: (gdb) bt #0 0x000000391800e40d in raise () from /lib64/libpthread-2.7.so #1 0x0000003c0a2c8aad in MagickSignalHandler (signal_number=6) at magick/magick.c:1067 #2 <signal handler called> #3 0x0000003917430ec5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #4 0x0000003917432970 in abort () at abort.c:88 #5 0x000000391742a11f in __assert_fail (assertion=0x3c0a35a168 "image->signature == 0xabacadabUL", file=0x3c0a35a276 "magick/blob.c", line=469, function=0x3c0a35aa95 "CloseBlob") at assert.c:78 #6 0x0000003c0a238648 in CloseBlob (image=0x617f70) at magick/blob.c:469 #7 0x00002aaaaaae8b3a in ReadPNGImage (image_info=0x60bae0, exception=0x603060) at coders/png.c:2837 #8 0x0000003c0a25ce90 in ReadImage (image_info=0x607940, exception=0x603060) at magick/constitute.c:389 #9 0x0000003c0a656ced in IdentifyImageCommand (image_info=0x603650, argc=2, argv=0x6078e0, metadata=0x7fff4a18c310, exception=0x603060) at wand/identify.c:285 #10 0x0000000000400bca in main (argc=2, argv=0x7fff4a18c428) at utilities/identify.c:101 #11 0x000000391741e074 in __libc_start_main (main=0x400b00 <main>, argc=2, ubp_av=0x7fff4a18c428, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fff4a18c418) at libc-start.c:220 #12 0x0000000000400a49 in _start () note that RHEL is also affected (all versions) p.s. I tried to report to upstream, but I have troubles sending to imagemagick-bugs ...
Created attachment 304619 [details] crash reproducer
It isn't crashing its calling abort() because it detects the image is corrupt. I'm strongly tended to close this as not a bug. Please explain why you believe the calling abort() upon invalid input is a bug.
> Please explain why you believe the calling abort() upon invalid input is a bug. because it drops core instead of telling that the image is corrupt and exiting cleanly?
(In reply to comment #3) > > Please explain why you believe the calling abort() upon invalid input is a > bug. > > because it drops core instead of telling that the image is corrupt and exiting > cleanly? It does tell the image is corrupt: Assertion `image->signature == 0xabacadabUL' failed. I will admit that is somewhat cryptic, but it is telling it. As for exiting cleanly, you are deliberately feeding it corrupt data, and then it calls abort(), which seems like a reasonable thing todo on corrupt input. As for abort dropping core, that only happens because you changed the core size ulimit from the Fedora default. Anyway I'll report this upstream and see what they have to say.
(In reply to comment #4) > It does tell the image is corrupt: > Assertion `image->signature == 0xabacadabUL' failed. > > I will admit that is somewhat cryptic, but it is telling it. ok, I confess I did not go after the exact meaning of the message ... but you would not expect the user to study the sources to know if it has to do something with the image file itself or if it is just some internal data? > As for exiting cleanly, you are deliberately feeding it corrupt data, yes, I am sooo nasty ... but it happens in real life that the data get corrupted while in transfer (or by some malicious hacker) and the software has to cope with it > and then it calls abort(), which seems like a reasonable thing todo on > corrupt input. As for abort dropping core, that only happens because you > changed the core size ulimit from the Fedora default. yes, I changed ulimit to be able to provide backtraces when software crashes I am not sure what the standars and programmers good practices say about using abort, but from my POV, if there is no error within the program itself, it should not drop core - for example, doing this nasty thing of feeding invalid input to mplayer does not result in dropping core: $ cp test.png test.mpg $ mplayer test.mpg MPlayer 1.0rc2-4.1.2 (C) 2000-2007 MPlayer Team CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (Family: 6, Model: 15, Stepping: 6) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing test.mpg. MPEG: Missing video stream!? Contact the author, it may be a bug :( libavformat file format detected. [mpeg @ 0x996480]Could not find codec parameters (Video: mpeg2video) LAVF_header: av_find_stream_info() failed Exiting... (End of file) (and it is not just mplayer, it is common practice) another problem is that if there are more input files, the program does not process the rest ... > Anyway I'll report this upstream and see what they have to say. ok, thanks
I;'ve just updated ImageMagick in rawhide (F-11 branch) to 6.4.5-5, this fixes this: [hans@localhost devel]$ identify ~/test.png identify: tRNS chunk has out-of-range samples for bit_depth `/home/hans/test.png' @ coders/png.c/PNGWarningHandler/1416. identify: Ignoring bad adaptive filter type `/home/hans/test.png' @ coders/png.c/PNGWarningHandler/1416. identify: Extra compressed data `/home/hans/test.png' @ coders/png.c/PNGErrorHandler/1399. identify: Corrupt image `/home/hans/test.png' @ coders/png.c/ReadPNGImage/2885.
great, thankyou for taking a look at it