Summary: | media-gfx/gimp-2.10.14-r1 - segmentation fault while running idle | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Theo van Rijn <theo.van.rijn> |
Component: | Current packages | Assignee: | Sergey Torokhov <torokhov-s-a> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info |
Description
Theo van Rijn
2020-02-19 20:49:38 UTC
> 3. upgraded from gimp-2.10.14 to gimp-2.10.14-r1. Gimp started behaving 'differently' after this upgrade; it appears to be using 1 core at 100%, even without an image loaded.
Do you mean different behaviour with cpu core after update to gimp revision -r1 or all listed items together?
The gimp revision bump is related only with python configuration phase before build and shouldn't affect build process or build result: there was changes during PYTHON_SINGLE_USEDEP / MULTI_USEDEP API conversion in python-single-r1.
I assume that the problem, especially with cpu load, is somehow related with OpenCL functionality. But this is not exclude the possibility of segfault for any others reasons.
Could you provide the information about steps of gcc switch to 9.2; kernel and system configuration for new amd gpu card?
(In reply to Sergey Torokhov from comment #1) > > 3. upgraded from gimp-2.10.14 to gimp-2.10.14-r1. Gimp started behaving 'differently' after this upgrade; it appears to be using 1 core at 100%, even without an image loaded. > > Do you mean different behaviour with cpu core after update to gimp revision > -r1 or all listed items together? The 100% cpu on one core correlates with starting and stopping Gimp. I'm very certain this did not happen before the bump as I have Gimp open all of the time and I would have noticed. > > The gimp revision bump is related only with python configuration phase > before build and shouldn't affect build process or build result: there was > changes during PYTHON_SINGLE_USEDEP / MULTI_USEDEP API conversion in > python-single-r1. > I agree after comparing the ebuilds; the Gimp code did not change with the bump. I did recompile the main dependencies (babl, GEGL, GLib, GdkPixbuf, etc) with gcc 92 but that did not make a difference. > I assume that the problem, especially with cpu load, is somehow related with > OpenCL functionality. But this is not exclude the possibility of segfault > for any others reasons. > > Could you provide the information about steps of gcc switch to 9.2; kernel > and system configuration for new amd gpu card? This change took some time. I reconfigure the kernel for amdgpu months ago but only bought and installed a Radeon 5500TX card two-and-a-half weeks ago. The card worked OK but was not stable so I upgraded to kernel 5.5.2 and Mesa 19.3.4. This setup is stable (so far). I removed nvidia-drivers and nvidia-cg-toolkit a week ago. I did notice I used to have an OpenCL config with Nvidia but that disappeared. Should I enable it again? E.g. by setting the opencl USE flag on mesa? BTW, thanks for looking into this Sergey. It appears that enabling the opencl USE flag on mesa did the trick. I'll do more tests tomorrow but the one-core-100%-load is gone and Gimp is working as expected. Gimp is stable and working fine. Re-emerging mesa with opencl was sufficient. There must be an undefined dependency. (In reply to Theo van Rijn from comment #4) > Gimp is stable and working fine. Re-emerging mesa with opencl was > sufficient. There must be an undefined dependency. Sorry for delay with answer. It's good to know that `mesa[opencl]` resolved issue. It's seems there was configuration conflict. I shall try to check if upstream already has issue about check if OpenCL support is presented in system before trying to activate it. Unfortunately the OpenCL support is still experimental in GIMP as mentioned in menu item "Edit - Preferences - System Resources - Hardware Acceleration" under "Use OpenCL" checkbox: > OpenCL drivers and support are experimental, > expected slowdown and possible crashes (please report). This option is disabled by default. As for undefined dependency in my opinion there are no any provided by upstream build option (I didn't find it) of gegl or gimp to enable/disable OpenCL support. While system OpenCL support in Gentoo fully depends on user defined make.conf VIDEO_CARDS variable + mesa[opencl] if nvidia-drivers isn't used. In case of nvidia-drivers there is seems own opencl implementation. P.S. Well, there is a gimp 2.10.18 is out yesterday (2.10.16 skipped due to critical bug). I need o update it. (In reply to Sergey Torokhov from comment #5) > Sorry for delay with answer. It's good to know that `mesa[opencl]` resolved > issue. It's seems there was configuration conflict. No problem at all; your initial remark about OpenCL was enough to find a solution. > > Unfortunately the OpenCL support is still experimental in GIMP as mentioned > in menu item "Edit - Preferences - System Resources - Hardware Acceleration" > under "Use OpenCL" checkbox: > > > OpenCL drivers and support are experimental, > > expected slowdown and possible crashes (please report). > > This option is disabled by default. It was disabled in my gimp configuration, I was not testing with opencl, just the CPU is enough for my photo editing. > P.S. > Well, there is a gimp 2.10.18 is out yesterday (2.10.16 skipped due to > critical bug). I need o update it. I'm looking forward to upgrade gimp. Could I close the issue? P.s. Gimp-2.10.18 is in portage tree but since now with disabled python2 plugins support. (In reply to Sergey Torokhov from comment #7) > Could I close the issue? Yes, please close this issue; the segfault did not re-occur. I now seem to have other issues with rendering, with both 2.10.14 and 2.10.18 but I will investigate these first. Thanks again for your help! |