Bug#903514: gimp: completely broken
Christoph Anton Mitterer
Version: 2.10.2-1
Severity: grave
Justification: renders package unusable
Hi.
Since some time the GIMP is completely broken.
In most cases it does not even start (e.g. when invoking
it from another program) or when:
$ gimp
or
$ gimp 0.jpg
(with 0.jpg not existing)
it simply hangs (with no GUI coming up)
when doing e.g.:
$ gimp Screenshot\ from\ 2018-06-02\ 04-36-57.png
Missing fast-path babl conversion detected, Implementing missing babl fast paths
accelerates GEGL, GIMP and other software using babl, warnings are printed on
first occurance of formats used where a conversion has to be synthesized
programmatically by babl based on format description
*WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double"
GIMP-Error: Unable to run plug-in "plugin-uncrop.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-resynth-sharpen.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-resynth-sharpen.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-resynth-fill-pattern.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-resynth-fill-pattern.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-resynth-enlarge.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-resynth-enlarge.py)
Failed to execute child process “python” (No such file or directory)
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
GIMP-Error: Unable to run plug-in "plugin-map-style.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-map-style.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-heal-transparency.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-heal-transparency.py)
Failed to execute child process “python” (No such file or directory)
GIMP-Error: Unable to run plug-in "plugin-heal-selection.py"
(/usr/lib/gimp/2.0/plug-ins/plugin-heal-selection.py)
Failed to execute child process “python” (No such file or directory)
One get's these weird python errors...
Even when Ctrl+C or killall gimp and so on, processes like:
10423 ? Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 35 33 -run 0
10443 ? Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 39 37 -run 0
10556 ? Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 47 45 -run 0
10571 ? Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 51 49 -run 0
are left behind
Trying to open or save files from within gimp, often leads to the GUI simply
hanging.
And even tools like the Free Select Tool are broken... on can start a selection
but not connect the two endpoints.
All this happens even with .config/GIMP and friends completel removed.
Cheers,
Chris.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gimp depends on:
ii gimp-data 2.10.2-1
ii libaa1 1.4p5-44+b2
ii libbabl-0.1-0 0.1.50-1
ii libbz2-1.0 1.0.6-8.1
ii libc6 2.27-4
ii libcairo2 1.15.10-3
ii libfontconfig1 2.13.0-5
ii libfreetype6 2.8.1-2
ii libgcc1 1:8.1.0-9
ii libgdk-pixbuf2.0-0 2.36.11-2
ii libgegl-0.4-0 0.4.2-1
ii libgexiv2-2 0.10.8-1
ii libgimp2.0 2.10.2-1
ii libglib2.0-0 2.56.1-2
ii libgs9 9.22~dfsg-2.1
ii libgtk2.0-0 2.24.32-2
ii libgudev-1.0-0 232-2
ii libharfbuzz0b 1.8.2-2
ii libheif1 1.3.2-1
ii libilmbase23 2.2.1-2
ii libjpeg62-turbo 1:1.5.2-2+b1
ii liblcms2-2 2.9-2
ii liblzma5 5.2.2-1.3
ii libmng1 1.0.10+dfsg-3.1+b5
ii libmypaint-1.3-0 1.3.0-2
ii libopenexr23 2.2.1-4
ii libopenjp2-7 2.3.0-1
ii libpango-1.0-0 1.42.1-2
ii libpangocairo-1.0-0 1.42.1-2
ii libpangoft2-1.0-0 1.42.1-2
ii libpng16-16 1.6.34-2
ii libpoppler-glib8 0.63.0-2
ii librsvg2-2 2.40.20-2
ii libstdc++6 8.1.0-9
ii libtiff5 4.0.9-6
ii libwebp6 0.6.1-2
ii libwebpdemux2 0.6.1-2
ii libwebpmux3 0.6.1-2
ii libwmf0.2-7 0.2.8.4-12
ii libx11-6 2:1.6.5-1
ii libxcursor1 1:1.1.15-1
ii libxext6 2:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxmu6 2:1.1.2-2
ii libxpm4 1:3.5.12-1
ii xdg-utils 1.1.3-1
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages gimp recommends:
ii ghostscript 9.22~dfsg-2.1
Versions of packages gimp suggests:
ii gimp-data-extras 1:2.0.2-1
ii gimp-help-de [gimp-help] 2.8.2-0.1
ii gimp-help-en [gimp-help] 2.8.2-0.1
pn gimp-python <none>
ii gvfs-backends 1.36.1-1+b1
ii libasound2 1.1.6-1
-- no debconf information
Jeremy Bicha
<cale...@scientia.net> wrote:
> Since some time the GIMP is completely broken.
about *when* things stopped working?
> GIMP-Error: Unable to run plug-in "plugin-uncrop.py"
> (/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py)
>
> Failed to execute child process “python” (No such file or directory)
Do you have anything unusual with your python install? Does python
otherwise work?
Thanks,
Jeremy Bicha
Christoph Anton Mitterer
> I don't know. It works fine here. Could you try to be more specific
> about *when* things stopped working?
mean though, that it wasn't introduced earlier.
Wasn't there recently some change in the python packaging, when Python
2 was split out into python2* packages (which the normal "python*"
packages depend upon however)?
> Does it help if you install gimp-python?
When starting plain:
$ gimp
or when opening some
$ gimp foo.png
it hangs at it's GUI splash screen at "python-eval.py".
After Ctrl+C there's a
24556 pts/6 Sl 0:00 /usr/bin/python2 /usr/lib/gimp/2.0/plug-ins/python-eval.py -gimp 14 13 -query 0
left.
> Do you have anything unusual with your python install?
only plain package installations as required for dependencies)
> Does python
> otherwise work?
It seems so... or at least soooo many other things in a normal desktop
Debian use python... nothing of that shows any issues recently.
Thanks!
Harald Wenninger
Version: 2.10.2-1
Followup-For: Bug #903514
Dear Maintainer,
I have the same problem.
Last week gimp was functioning normally, now it doesn’t even start up
and segfaults when interrupted by Ctrl+C.
My python installation is fully functional, I use python every day.
Regards,
Harald
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages gimp depends on:
ii gimp-data 2.10.2-1
ii libaa1 1.4p5-44+b2
ii libbabl-0.1-0 1:0.1.52-dmo1
ii libbz2-1.0 1.0.6-8.1
ii libc6 2.27-4
ii libcairo2 1.15.10-3
ii libfontconfig1 2.13.0-5
ii libfreetype6 2.8.1-2
ii libgcc1 1:8.1.0-9
ii libgdk-pixbuf2.0-0 2.36.11-2
ii libgegl-0.4-0 1:0.4.4-dmo1
ii libgexiv2-2 0.10.8-1
ii libgimp2.0 2.10.2-1
ii libglib2.0-0 2.56.1-2
ii libgs9 9.22~dfsg-2.1
ii libgtk2.0-0 2.24.32-2
ii libgudev-1.0-0 232-2
ii libharfbuzz0b 1.8.2-2
ii libheif1 1.3.2-1
ii libilmbase23 2.2.1-2
ii libjpeg62-turbo 1:1.5.2-2+b1
ii liblcms2-2 2.9-2
ii liblzma5 5.2.2-1.3
ii libmng1 1.0.10+dfsg-3.1+b5
ii libmypaint-1.3-0 1:1.3.0-dmo6
pn gimp-data-extras <none>
pn gimp-help-en | gimp-help <none>
ii gimp-python 2.10.2-1
pn gvfs-backends <none>
James Van Zandt
Pascal Giard
Debian GNU/Linux (http://www.debian.org)
TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch)
Pascal Giard
James Van Zandt
On 09/08/2018 00:22, Alexis Murzeau wrote:
> On 08/08/2018 00:59, Alexis Murzeau wrote:
>> severity 903514 important
>> thanks
>>
>>> Reassigning to glibc with affects on openblas and gimp as this is caused
>>> by a deadlock inside glibc.
>>
>> Done.
>>
>> Lowering severity as this does not render any package unusable by
>> themselves, but only a combination of them (GIMP + OpenBLAS).
>>
>> I think a workaround solution against GIMP OpenBLAS should be done as
>> I'm not sure a good solution will emerge in glibc given attempts done in
>> the past. The work to be done seems non trivial.
>>
>> My though on possible solutions:
>> * Add a breaks between GIMP and OpenBLAS
>> * Disable TLS in OpenBLAS build (if possible, but this would cause a
>> performance loss for users that use OpenBLAS without gimp)
>> * Add a delay in GIMP to not load then close libraries too fast (so
>> OpenBLAS threads are fully initialized when dl_close is called on it)
>>
>
> Hi,
>
> I've posted a issue on openblas upstream project [0] and they suggested
> some solutions.
> One of them is to disable the use of compiler supported TLS and instead
> use pthreads.
>
> I tested this and it seems to fix deadlocks while starting gimp (I tried
> without arguments, with a non existing file and with an existing file).
>
> I've pushed a merge request with the patch at [1].
> I've also asked openblas upstream if this patch could be a good solution.
>
> In that case would it be possible to have this patch tested for ones who
> have major instabilities with gimp + openblas ?
>
> Thanks :)
>
Hi,
I've updated the merge request [0] with the upstream proposed patch [1].
@openblas maintainers, maybe someone can build a package with this patch
and upload to experimental so others can check if gimp works fine with it ?
I've myself tested it and gimp does not deadlock.
I can provide a binary package that include this patch, but I'm not sure
this is the best thing to do (I'm not the official maintainer, nor know
a good place to upload it).
[0] https://salsa.debian.org/science-team/openblas/merge_requests/1
[1] https://github.com/xianyi/OpenBLAS/pull/1726
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Jackie
On 10/08/2018 23:27, Alexis Murzeau wrote:I can provide a binary package that include this patch, but I'm not sure this is the best thing to do (I'm not the official maintainer, nor know a good place to upload it).
As I was requested to provide binary package to test the patch, I'm providing this as version `0.3.2+ds-1.1~1patchTLS` built with sbuild at [0]. Instructions are on the same page [0]: execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001` and add `deb https://amurzeau.github.io/apt-repository unstable main` to sources.list. This APT repository contains both the source and amd64 binary packages. If you try it, please tell if it works. [0] https://amurzeau.github.io/apt-repository/
Sébastien Villemot
> On 09/08/2018 00:22, Alexis Murzeau wrote:
> > On 08/08/2018 00:59, Alexis Murzeau wrote:
> > > severity 903514 important
> > > thanks
> > >
> > > > Reassigning to glibc with affects on openblas and gimp as this is caused
> > > > by a deadlock inside glibc.
> > some solutions.
> > One of them is to disable the use of compiler supported TLS and instead
> > use pthreads.
I think this should fix the original issue, i.e. the gimp+openblas
deadlock. Please let me know if this is not the case.
Best,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Aurelien Jarno
brought to light when enabling TLS support in openblas and not by a new
glibc version.
Right now the bug has been workarounded by disabling TLS support in
openblas. The way to handle this bug is to write a small testcase that
can be forwarded upstream. It's not an easy task though.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://www.aurel32.net
Wang Jianlin
Ich beabsichtige, Ihnen einen Teil meines Vermögens als freiwillige finanzielle Spende zukommen zu lassen.
Wang Jianlin
Wanda-Gruppe