Red Hat Bugzilla – Bug 445341
ImageMagick crashes at magick/blob.c:469: CloseBlob with malformed png
Last modified: 2008-11-18 05:04:53 EST
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)
Steps to Reproduce:
1. identify test.png
$ identify test.png
identify: magick/blob.c:469: CloseBlob: Assertion `image->signature ==
Aborted (core dumped)
it does not crash ...
#0 0x000000391800e40d in raise () from /lib64/libpthread-2.7.so
#1 0x0000003c0a2c8aad in MagickSignalHandler (signal_number=6) at
#2 <signal handler called>
#3 0x0000003917430ec5 in raise (sig=<value optimized out>)
#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)
#9 0x0000003c0a656ced in IdentifyImageCommand (image_info=0x603650, argc=2,
argv=0x6078e0, metadata=0x7fff4a18c310, exception=0x603060)
#10 0x0000000000400bca in main (argc=2, argv=0x7fff4a18c428) at
#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
#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
Created attachment 304619 [details]
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
because it drops core instead of telling that the image is corrupt and exiting
(In reply to comment #3)
> > Please explain why you believe the calling abort() upon invalid input is a
> because it drops core instead of telling that the image is corrupt and exiting
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,
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.
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.
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