Menu

#585 Assertion Failure in coders/png.c:7503

v1.0_(example)
closed-fixed
None
5
2018-12-17
2018-12-12
No

There is an assertion failure in coders/png.c:7503, which could be triggered by the POC below. What's weired is that the length of the filename must be more than 35 or such crash will not be triggered.
When the filename is more than 35 bytes, the indexse in png.c:7494 is

$ display indexes
1: indexes = (const IndexPacket *) 0x9fb4e0 "rocess ID\n      0"

And when the filename is less than 36 bytes, the indexes is

1: indexes = (const IndexPacket *) 0xa0de40 ""

I find this is caused by the difference in the addresses of cache_info returned by malloc between such two situations, but I don't know why.

  1. Version : 89e436221567+ (GraphicsMagick-1_3)
  2. Libs: -ljbig -lwebp -lwebpmux -llcms2 -ltiff -lfreetype -ljpeg -lpng12 -lwmflite -lXext -lSM -lICE -lX11 -llzma -lbz2 -lxml2 -lz -lm -lpthread
  3. System: Ubuntu 16.04.4 LTS

To produce it,

./configure   'CFLAGS=-g -O0' 'CXXFLAGS=-g -O0' && make -j16 &&make install
$gm convert $POC 1.mng
gm: coders/png.c:7503: WriteOnePNGImage: Assertion `(unsigned long) index < number_colors' failed.
gm convert: abort due to signal 6 (SIGABRT) "Abort"...
Aborted (core dumped)

GDB info:

$ bt
#0  0x00007fbaf3ba7428 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007fbaf3ba9187 in __GI_abort () at abort.c:118
#2  0x00000000004809bc in MagickPanicSignalHandler (signo=0x6) at magick/magick.c:828
#3  <signal handler called>
#4  0x00007fbaf3ba7428 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:54
#5  0x00007fbaf3ba902a in __GI_abort () at abort.c:89
#6  0x00007fbaf3b9fbd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x6fb9f8 "(unsigned long) index < number_colors", 
    file=file@entry=0x6f99b3 "coders/png.c", line=line@entry=0x1d4f, function=function@entry=0x6fca50 <__PRETTY_FUNCTION__.13558> "WriteOnePNGImage")
    at assert.c:92
#7  0x00007fbaf3b9fc82 in __GI___assert_fail (assertion=0x6fb9f8 "(unsigned long) index < number_colors", file=0x6f99b3 "coders/png.c", line=0x1d4f, 
    function=0x6fca50 <__PRETTY_FUNCTION__.13558> "WriteOnePNGImage") at assert.c:101
#8  0x000000000054ecb8 in WriteOnePNGImage (mng_info=0x1aed1a0, image_info=0x1ae9e10, imagep=0x1addde0) at coders/png.c:7503
#9  0x0000000000557ede in WriteMNGImage (image_info=0x1ae9e10, image=0x1addde0) at coders/png.c:10121
#10 0x00000000004510d9 in WriteImage (image_info=0x1adbc90, image=0x1addde0) at magick/constitute.c:2245
#11 0x0000000000451771 in WriteImages (image_info=0x1ad7610, image=0x1addde0, filename=0x1ad6c90 "1.mng", exception=0x7fffb3ac0fd0)
    at magick/constitute.c:2403
#12 0x000000000042169c in ConvertImageCommand (image_info=0x1ad7610, argc=0x3, argv=0x1ad9760, metadata=0x0, exception=0x7fffb3ac0fd0)
    at magick/command.c:6101
#13 0x0000000000427f28 in MagickCommand (image_info=0x1ad7610, argc=0x3, argv=0x7fffb3ac1960, metadata=0x7fffb3ac0fb8, exception=0x7fffb3ac0fd0)
    at magick/command.c:8886
#14 0x000000000044121e in GMCommandSingle (argc=0x3, argv=0x7fffb3ac1960) at magick/command.c:17408
#15 0x0000000000441347 in GMCommand (argc=0x4, argv=0x7fffb3ac1958) at magick/command.c:17461
#16 0x000000000040bf06 in main (argc=0x4, argv=0x7fffb3ac1958) at utilities/gm.c:61
#17 0x00007fbaf3b92830 in __libc_start_main (main=0x40bee6 <main>, argc=0x4, argv=0x7fffb3ac1958, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffb3ac1948) at ../csu/libc-start.c:291
#18 0x000000000040be19 in _start ()
1 Attachments

Discussion

  • Bob Friesenhahn

    Bob Friesenhahn - 2018-12-12

    It is recommended to attach the POC file in a zip or tar wrapper since
    SourceForge has a habit of re-writing image formats that it
    understands.

    What I download may have no resemblance to what you uploaded.

    Bob

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2018-12-12
     
  • Bob Friesenhahn

    Bob Friesenhahn - 2018-12-12

    It seems that the POC file may be ok. It appears to be a DIB file and not a PNG file. Valgrind shows that there is definitely something wrong.

     
  • Augustus Wang

    Augustus Wang - 2018-12-13

    I just attach the POC file in poc.zip. And the poc.png in the zip is a copy of the POC file with another filename and it will not trigger the crash.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2018-12-16

    It seems likely that the DIB reader is doing something wrong since valgrind also shows issues during encoding if the output is written to MIFF format.

     
  • Bob Friesenhahn

    Bob Friesenhahn - 2018-12-17
    • status: open --> closed-fixed
    • private: Yes --> No
     
  • Bob Friesenhahn

    Bob Friesenhahn - 2018-12-17

    The problem is that the DIB file claims to have aspects of both a colormapped file and one containing direct pixel values. It claims to have a colormap yet it also claims to be 32-bits. Only 8-bit/sample and less use a colormap. The end result is that the direct case is used and so the indexes data is never initialized.

    This problem is fixed by Mercurial changeset changeset 15869:648e2b406589.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.