Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Trying to convert an image, I got convert to suddenly crash. Rerunning the same command-line under valgrind, I see the following errors (before the actual crash even happens):
==15439== Command: convert -bordercolor Transparent -border 1x1 ../Tango/22x22/actions/document-print-preview.png 24x24/actions/document-print-preview.png
==15439==
==15439== Invalid free() / delete / delete[] / realloc()
==15439== at 0x35E27: free (in /opt/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==15439== by 0x1C470E: DestroySemaphoreInfo (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==15439== by 0x136CF2: DestroyLinkedList (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==15439== by 0xA9F9B: GetConfigureOptions (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==15439== by 0x1523EF: ??? (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==15439== by 0x152EB6: LogComponentGenesis (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==15439== by 0x157570: MagickCoreGenesis (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==15439== by 0x804892D: ??? (in /opt/bin/convert)
==15439== by 0x8048859: ??? (in /opt/bin/convert)
==15439== by 0x8048717: ??? (in /opt/bin/convert)
==15439== by 0x6: ???
==15439== Address 0x3003180 is not stack'd, malloc'd or (recently) free'd
The same error is repeated several times -- with the address, that's passed to free() -- changing slightly. Is it possible, some static memory is passed down to free() (or RelinquishSemaphoreMemory() rather ) by mistake?
This is on FreeBSD-10.1. Both i386 (32-bit) and amd64 (64-bit) show the same error under valgrind, although the 64-bit version successfully converts at the end anyway...
As per subject, I'm seeing this problem with 6.9.0-0.
Does this happen on all input images, or just this one? If just this one, please supply the input file.
Seems to happen before the image is even accessed -- for example, with a bogus (nonexistent) filename...
Actually, the same problem exists in other similar destructors:
==53968== Invalid free() / delete / delete[] / realloc()
==53968== at 0x35E27: free (in /opt/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==53968== by 0x15A3DF: RelinquishAlignedMemory (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0x7A5D8: DestroyPixelCache (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0x7A3BB: DestroyImagePixels (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0x14358F: DestroyImage (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0x14730B: SetImageInfo (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0xAB420: ReadImage (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0xAC785: ReadImages (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0x30EB5B: ConvertImageCommand (in /opt/lib/libMagickWand-6.Q16HDRI.so.2.0.0)
==53968== by 0x38FC51: MagickCommandGenesis (in /opt/lib/libMagickWand-6.Q16HDRI.so.2.0.0)
==53968== by 0x8048962: ??? (in /opt/bin/convert)
==53968== by 0x8048859: ??? (in /opt/bin/convert)
==53968== Address 0x3007e00 is not stack'd, malloc'd or (recently) free'd
And
==53968== Invalid free() / delete / delete[] / realloc()
==53968== at 0x35E27: free (in /opt/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==53968== by 0x15A0AD: RelinquishVirtualMemory (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0x26B4F65: ??? (in /opt/lib/ImageMagick-6.9.0/modules-Q16HDRI/coders/png.so)
==53968== by 0x269E23B: ??? (in /opt/lib/ImageMagick-6.9.0/modules-Q16HDRI/coders/png.so)
==53968== by 0xAB6DB: ReadImage (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0xAC785: ReadImages (in /opt/lib/libMagickCore-6.Q16HDRI.so.2.0.0)
==53968== by 0x30EB5B: ConvertImageCommand (in /opt/lib/libMagickWand-6.Q16HDRI.so.2.0.0)
==53968== by 0x38FC51: MagickCommandGenesis (in /opt/lib/libMagickWand-6.Q16HDRI.so.2.0.0)
==53968== by 0x8048962: ??? (in /opt/bin/convert)
==53968== by 0x8048859: ??? (in /opt/bin/convert)
==53968== by 0x8048717: ??? (in /opt/bin/convert)
==53968== by 0x6: ???
==53968== Address 0x300c080 is not stack'd, malloc'd or (recently) free'd
Unfortunately we cannot reproduce this problem under Fedora / CentOS / Windows / Mac OS X. We do not have access to a FreeBSD system. Try building ImageMagick with CFLAGS -g. The stack trace will then report source line numbers which would be helpful with our forensics. If the problem only happens with a couple of your images, consider posting a URL to your image(s) to help us reproduce the problem.
