php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60946 segfault in imagick zim_imagick_getimageprofile
Submitted: 2012-02-01 08:35 UTC Modified: 2015-04-27 13:54 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: mqudsi at neosmart dot net Assigned: danack
Status: Assigned Package: imagick (PECL)
PHP Version: 5.3.9 OS: ubuntu lucid
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-02-01 08:35 UTC] mqudsi at neosmart dot net
Description:
------------
I have a fully reproducable (on my machine) crash of the PHP imagick module. I'm 
running PHP 5.3.9-2~lucid+2 w/ Suhosin 0.9.29

PHP is running as php-fpm behind an nginx frontend, using unix sockets for 
communication.

This is the backtrace:


Program received signal SIGSEGV, Segmentation fault.
0x00ee77a0 in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0x00ee77a0 in ?? () from /lib/tls/i686/cmov/libc.so.6
#1  0x00967d60 in zim_imagick_getimageprofile ()
   from /usr/lib/php5/20090626+lfs/imagick.so
#2  0x08326adb in execute_internal ()
#3  0x007b9ea8 in ?? () from /usr/lib/php5/20090626+lfs/suhosin.so
#4  0x08352448 in ?? ()
#5  0x0832948e in execute ()
#6  0x007ba314 in ?? () from /usr/lib/php5/20090626+lfs/suhosin.so
#7  0x08352136 in ?? ()
#8  0x0832948e in execute ()
#9  0x007ba314 in ?? () from /usr/lib/php5/20090626+lfs/suhosin.so
#10 0x08352136 in ?? ()
#11 0x0832948e in execute ()
#12 0x007ba314 in ?? () from /usr/lib/php5/20090626+lfs/suhosin.so
#13 0x08352136 in ?? ()
#14 0x0832948e in execute ()
#15 0x007ba314 in ?? () from /usr/lib/php5/20090626+lfs/suhosin.so
#16 0x08352136 in ?? ()
#17 0x0832948e in execute ()
#18 0x007ba314 in ?? () from /usr/lib/php5/20090626+lfs/suhosin.so
#19 0x082fe956 in zend_execute_scripts ()
#20 0x082a2064 in php_execute_script ()
#21 0x0839bd79 in ?? ()


I also have the strace output, don't know if that's helpful:
http://pastebin.com/HgVYq6ve

I apologize if this report is less than helpful. Please let me know what I can 
provide in particular to make it more useful.

Thank you.

Expected result:
----------------
no segfault

Actual result:
--------------
segfault

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-03-15 17:10 UTC] spam at ethaniel dot com
Try limiting Imagick to using only 1 thread.
Add this code before newImage:

$img->setResourceLimit(6, 1); // 6 means "limit threads to"
 [2013-10-09 07:34 UTC] datibbaw@php.net
Have you tried disabling suhosin?
 [2013-12-03 11:30 UTC] mike@php.net
-Assigned To: +Assigned To: mkoppanen
 [2015-01-05 03:34 UTC] danack@php.net
If possible, can you provide the image that shows this problem?

I believe there may be some invalid memory access in the getImageProfile routines (according to valgrind) which would lead to a crash, but the ImageMagick team like to have a reproducible crash before fixing an issue, rather than accepting that invalid memory accesses are always bad.
 [2015-01-28 22:45 UTC] nperson at gmx dot de
I can confirm this bug, but can reproduce it only on our Gentoo production server using php-cli. Trying to reproduce inside my VM with same OS, versions and compile flags fails. 

My test script executed with 'php -n -d extension=imagick.so t.php' is:
<?php
$i = new Imagick('Transparent.png');
$i->getImageProfiles();
?>

The PNG image used can be downloaded from:
http://upload.wikimedia.org/wikipedia/commons/8/8c/Transparent.png

I was able to narrow down under the circumstances under which the segfault occurs. The source image must be PNG with an alpha channel (see above). Disabling any other non-core extensions and ensuring opcache is also disabled doesn't help. Also disabling multiple threads via 'setResourceLimit(6, 1)' doesn't help.

The script seems to executes fine until the end, but during shutdown segfaults.

I've temporarily tried to compile ext-imagick, imagemagick and PHP with debug symbols and was able to get a core dump. Nonetheless the BT isn't containing any detailed information. What am I doing wrong here? I'm new to gdb, sorry.

Reading symbols from /usr/bin/php...done.
[New LWP 30385]
[New LWP 30384]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `php -n -d extension=imagick.so t.php'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007ffe6a4eab50 in ?? ()
(gdb) bt
#0  0x00007ffe6a4eab50 in ?? ()
#1  0x00007ffe6a4e935e in ?? ()
#2  0x0000000000000000 in ?? ()

Versions
--------
ext-imagick: 3.1.2

Version: ImageMagick 6.9.0-3 Q16 x86_64 2015-01-28 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
Features: DPC Modules OpenMP
Delegates (built-in): bzlib gslib jng jpeg lcms ltdl png ps tiff xml zlib

libpng: 1.6.16

PHP 5.5.21-pl0-gentoo (cli) (built: Jan 28 2015 22:12:01) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

PHP Version => 5.5.21-pl0-gentoo

System => Linux a 3.17.7-gentoo #1 SMP Mon Jan 5 13:34:45 UTC 2015 x86_64
Build Date => Jan 28 2015 22:11:39
Configure Command =>  './configure'  '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--prefix=/usr/lib64/php5.5' '--mandir=/usr/lib64/php5.5/man' '--infodir=/usr/lib64/php5.5/info' '--libdir=/usr/lib64/php5.5/lib' '--with-libdir=lib64' '--without-pear' '--disable-maintainer-zts' '--enable-bcmath' '--with-bz2=/usr' '--enable-calendar' '--enable-ctype' '--with-curl=/usr' '--enable-dom' '--without-enchant' '--enable-exif' '--enable-fileinfo' '--enable-filter' '--enable-ftp' '--without-gettext' '--without-gmp' '--enable-hash' '--without-mhash' '--with-iconv' '--enable-intl' '--enable-ipv6' '--enable-json' '--without-kerberos' '--enable-libxml' '--with-libxml-dir=/usr' '--enable-mbstring' '--with-mcrypt=/usr' '--without-mssql' '--with-onig=/usr' '--with-openssl=/usr' '--with-openssl-dir=/usr' '--enable-pcntl' '--enable-phar' '--enable-pdo' '--enable-opcache' '--without-pgsql' '--enable-posix' '--without-pspell' '--without-recode' '--enable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap' '--enable-sockets' '--with-sqlite3=/usr' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--without-fpm-systemd' '--without-tidy' '--enable-tokenizer' '--disable-wddx' '--enable-xml' '--enable-xmlreader' '--enable-xmlwriter' '--without-xmlrpc' '--with-xsl=/usr' '--enable-zip' '--with-zlib=/usr' '--disable-debug' '--enable-dba' '--without-cdb' '--without-db4' '--disable-flatfile' '--with-gdbm=/usr' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir' '--without-vpx-dir' '--with-gd' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-pdo-dblib' '--with-pdo-mysql=mysqlnd' '--without-pdo-pgsql' '--with-pdo-sqlite=/usr' '--without-pdo-odbc' '--with-readline=/usr' '--without-libedit' '--without-mm' '--with-pic' '--with-pcre-regex=/usr' '--with-pcre-dir=/usr' '--with-config-file-path=/etc/php/cli-php5.5' '--with-config-file-scan-dir=/etc/php/cli-php5.5/ext-active' '--disable-embed' '--enable-cli' '--disable-cgi' '--disable-fpm' '--without-apxs2'
 [2015-04-01 17:19 UTC] danack@php.net
-Assigned To: mkoppanen +Assigned To: danack
 [2015-04-01 17:19 UTC] danack@php.net
Assigning to myself to investigate.
 [2015-04-02 00:07 UTC] danack@php.net
nperson, I'm pretty certain that what you're seeing is a different issue. The crash that was originally reported was definitely inside the getimageprofile function, and the crash that I think would happen for this issue would only occur in there.

Sorry - I'm unable to replicate it with that image.

If anyone is still seeing this issue, please try running it against valgrind to get a bit more info.
valgrind --malloc-fill=ff --track-origins=yes /usr/bin/php test.php
 [2015-04-05 14:43 UTC] mqudsi at neosmart dot net
It is unfortunate that the imagemagick team is taking this approach. It is no wonder that their code is singlehandedly responsible for a great majority of the memory access violations and memory leaks in many of the problematic cases with PHP deployment that I've come across. Regardless of whether or not that particular invalid memory access is responsible for a crash or not, this is a really bad policy to have and does not inspire confidence in their code.
 [2015-04-25 15:44 UTC] nperson at gmx dot de
Thank you danack, for working on this issue.

I've rerun the offending script through gdb and was able to get more information this time. I've also run it through valgrind. 

https://gist.github.com/davidpersson/d43555552ad9fa486c37

If my the bug I'm seeing isn't the same as the original reported one, I can open a new ticket for that. Can you give any hints on how to describe/title that bug?
 [2015-04-27 13:40 UTC] danack@php.net
Hi Nperson,

That is a different issue - it looks to be caused by OpenMP. The libgomp.so.1 library is the name of the library file for OpenMP.

Can you read the advice at https://github.com/mkoppanen/imagick#openmp - which basically says how to avoid using OpenMP.

At this time I'm not going to investigate how to fix it properly - at a rough guess it's going to take a week just to find the real cause of the issue, with no guarantee that a fix would be possible as I believe the threading used in OpenMP is compatible with other threading libraries being used at the same time.

For everyone else - I still think there is an issue in getimageprofile for certain images, but I can only investigate if someone provides a reproducible test image/case.

cheers
Dan
 [2015-04-27 13:54 UTC] mqudsi at neosmart dot net
This was three years ago, but if there's any way I can find an image modified on my machine on that day, I'll see if it exhibits the behavior and share.
 [2015-04-27 21:45 UTC] nperson at gmx dot de
Alright, sorry for unintentionally highjacking of the ticket. I've suggested to build imagick without openmp by default here https://bugs.gentoo.org/show_bug.cgi?id=547922. I've also found the source of my problem (it was an old ghostscript version, I had imagemagick compiled with ghostscript).
 
PHP Copyright © 2001-2015 The PHP Group
All rights reserved.
Last updated: Tue Sep 01 05:01:30 2015 UTC