| Summary: | dev-php/pecl-imagick segfaults with media-gfx/imagemagick[openmp] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David Persson <nperson> |
| Component: | [OLD] Development | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | codec, dilfridge, forza, mjo, nperson, sam, web |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109634 https://github.com/Imagick/imagick/issues/609 https://sourceware.org/bugzilla/show_bug.cgi?id=17621 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | test script, emerge --info output, gdb backtraces, valgrind output | ||
|
Description
David Persson
2015-04-27 19:07:59 UTC
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. |
