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: https://bugs.php.net/bug.php?id=60946#1430142001
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 <grknight@gentoo.org> +pecl-imagick-3.1.2-r1.ebuild, + +pecl-imagick-3.3.0_rc1.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 # https://github.com/mkoppanen/imagick#openmp RDEPEND=">=media-gfx/imagemagick-6.2.4:=[-openmp]" DEPEND="${RDEPEND} 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
Hi, just chiming in that I have also run a Nextcloud and wiki server with imagemagick and openmp for many years and have had no issues at all. So I also think that providing an openmp use-flag for pecl-imagick would be a good thing.
Same here, currently having to remove that forced use flag in local repo. Would be nice to remove it if it is no longer needed. (or make it selectable with an openmp use flag)
Thanks sam. Unless I'm mistaken, the new discussions only strengthen the case for the existing USE dependency on -openmp. While it may be inconvenient, it's pretty easy to override if you (think you) know what you're doing. And the alternative would be to let people build web servers that might segfault.
Mentioned tickets seem to be resolved already - therefore maybe there is a chance for accepting openmp flag to imagick?
(In reply to Marcin from comment #12) > Mentioned tickets seem to be resolved already - therefore maybe there is a > chance for accepting openmp flag to imagick? The one (still unresolved) problem is, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109634 > libgomp can be only dlopened in threaded apps if there is still space in the static TLS surplus, which unfortunately some versions of glibc use even for normal TLS rather than just static TLS. So, LD_PRELOAD=libgomp.so.1, or link the program with libgomp.so.1 rather than just its libraries, or dlopen it before spawning threads. It's probably a rare scenario, but I would guess that if you use imagemagick in threads, there's still a chance that it will segfault on you. I guess I'm willing to try it though, given how popular of a request it is.
