Created attachment 402118 [details]
test script, emerge --info output, gdb backtraces, valgrind output
I'm having issues using pecl-imagick - I'm getting reproducible segfaults with both version 3.1.2 and 3.2.0_rc1.
I can't describe what exactly triggers the faulty behavior. For one it's definitely the getimageprofile on PNGs, but other segfaults are seen seemingly random. Only certain images seem to trigger it, though.
It's very likely that the problems described above are cause by the extension being build with OpenMP support. The author of the extension suggests to disable OpenMP, please see https://github.com/mkoppanen/imagick#openmp for more information.
It would be great to have a USE flag for that, or disable OpenMP for imagick by default.
I've attached the test script, my emerge --info as well as gdb backtraces and valgrind checks.
This bug has been submitted to the PHP bug tracker earlier:
I think I was able to fix the - in my case - root cause through some trial and error.
Sorry for submitting the bug. Although the note from the author regarding OpenMP still stands. Whenever imagick segfaults the first thing one is suggested is disabling OpenMP.
I had imagemagick compiled with the ghostscript use flag and 9.10-r2 of ghostscript installed, after unmasking and installing 9.15-r1 the segfaults went away.
Thanks a lot for your time and great work!
I've forgotten to mention that I've recompiled imagemagick with "-openmp" that fixed the segfaults on profiling images (see original test script). The 2nd issue with profiling images converted from pdfs was fixed by the gs update to 9.15.
+*pecl-imagick-3.3.0_rc1 (29 Apr 2015)
+*pecl-imagick-3.1.2-r1 (29 Apr 2015)
+ 29 Apr 2015; Brian Evans <email@example.com> +pecl-imagick-3.1.2-r1.ebuild,
+ Verison bump; Revision bump to fix bug 547922 disallowing openmp
So is this actually still a problem? A few years have passed, should we still assume that openMP will not work with pecl-imagick? In your case the problem was actually caused by ghostscript and not directly by openMP, so should we keep restrict imagemagick to a single thread globally simply because of a vague and possibly outdated warning?
If pecl-imagick is worried about using openMP, it can restrict imagemagick to a single thread by using the appropriate API's, which is described on the mentioned github page:
Disable the use of threads in ImageMagick via Imagick by calling: Imagick::setResourceLimit(\Imagick::RESOURCETYPE_THREAD, 1); or Imagick::setResourceLimit(6, 1); if your version of ImageMagick does not contain the RESOURCETYPE_THREAD constant.
So if anything, I'd rather have an ebuild patch that will make pecl-imagick issue the above initialization before it calls ImageMagick further, than to have it cause a system-wide restriction on ImageMagick...
Otherwise, if imagemagick with openMP as such was a problem indeed, we'd actually have to disable openMP for any stable build of it. But I think the problem lies more in that using libraries concurrently _via_ an openMP enabled ImageMagick that aren't thread safe is the cause for these problems, and openMP gets the blame unfairly.
The test script runs just fine on my machine with openMP enabled (against a local pecl-imagick ebuild with the RDEPEND removed.)
So I am not claiming I am neccessarily right about all this, just wondered how everybody thinks about this in 2019...
(In reply to Alexander Wessel from comment #4)
> So if anything, I'd rather have an ebuild patch that will make pecl-imagick
> issue the above initialization before it calls ImageMagick further, than to
> have it cause a system-wide restriction on ImageMagick...
> So I am not claiming I am neccessarily right about all this, just wondered
> how everybody thinks about this in 2019...
This sounds fine to me. We could add an "openmp" USE flag for pecl-imagick, too, and then
* If it's set, require media-gfx/imagemagick:=[openmp].
* If it's not set, disable threads using that initialization trick.
That way people get the best of both worlds. If threads work; then great. If not, they can be disabled only in pecl-imagick.
Ok, what about august of 2020?
Why this is still in pecl-imagick/pecl-imagick-3.4.4.ebuild if this bug is fixed?
# imagemagick[-openmp] is needed wrt bug 547922 and upstream
test? ( >=media-gfx/imagemagick-6.2.4:=[jpeg,png,svg,truetype,xml] )"
I have been using openmp in imagemagick on all the servers I use and I have had no problems for several years
If it would be good to have a flag to activate it or not to check the openmp flag