Comment 10 for bug 1549942

On Sun, Mar 6, 2016 at 12:57 AM, Steve Langasek
<email address hidden> wrote:
> Hi Nish,
>
>> - d/tests/control: limit imagemagick to 1 thread to avoid openmp
>> related segfaults.
>
> This implies that php-imagick doesn't work correctly unless
> MAGICK_THREAD_LIMIT=1 is set; which clearly will not be the case out of
> the box. So I don't consider this a valid workaround for test failures,
> as it implies the code will still segfault in production.

I'm actually following the recommendations upstream for php-imagick
(https://github.com/mkoppanen/imagick#openmp). I believe this is
already a known issue with the imagemagick/openmp code and the
php-imagick maintainer implies this is where they spend a lot of their
time (https://github.com/mkoppanen/imagick/issues/138).

The bug is in imagemagick, though, not in php-imagick. I agree it's a
non-ideal fix, but the alternative is for (in my testing) basically
every test to fail. I will spend some time on Monday debugging
imagemagick with the fixes already mentioned in this bug applied to
see if it is another simple missing backport.

Alternatively, php-imagick *could* change the configuration of
imagemagick when installed. But I don't think that is normal or
possibly even allowed by the Debian manual.

The underlying issue here is that php-imagick and imagemagick need to
be kept in sync -- any modification of one must be tested against the
other for regressions (and that is not currently done, afaict). So
when backports to imagemagick occur, they are self-consistent (as far
as imagemagick's own tests go), but consumers of the API seem to break
(php-imagick's tests).