Try limiting Imagick to using only 1 thread.
Add this code before newImage:

$img->setResourceLimit(6, 1); // 6 means "limit threads to"

Have you tried disabling suhosin?

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.

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'

Assigning to myself to investigate.

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

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.

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?

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

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.

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).

Hi mqudsi,

As I'm unable to investigate this issue without an image that shows the issue,

As getImageProfiles is now covered in the tests, I'm going to set this issue to 'feedback', which will naturally lead to the issue being moved to 'No feedback' state in a couple of weeks without any further action.

If you rediscover an image that shows this problem, please either reopen this issue, or open another one. btw I wasn't looking after Imagick when you opened the issue...I usually look at bugs sooner rather than 3 years..

cheers
Dan
Ack

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.