gimp 2.10.28 bug with kernel 5.14...

[michaelhm]

this below ocurres with Linux 5.14.xx kernel, it does not appear until 5.13
there is no rule how to make it happen, it just happens while executing any function
gimp is keeping working but after most functions have no effect on the current image, closing the image and opening it works normal until the thing pops up again

Code: Select all

<!-- Copy-paste this whole debug data to report to developers -->


```
GNU Image Manipulation Program version 2.10.28
git-describe: GIMP_2_10_28
Build: unknown rev 0 for linux
# C compiler #
	Using built-in specs.
	COLLECT_GCC=gcc
	COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
	OFFLOAD_TARGET_NAMES=nvptx-none:hsa
	OFFLOAD_TARGET_DEFAULT=1
	Target: x86_64-linux-gnu
	Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
	Thread model: posix
	gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) 

# Libraries #
using babl version 0.1.88 (compiled against version 0.1.88)
using GEGL version 0.4.32 (compiled against version 0.4.32)
using GLib version 2.64.6 (compiled against version 2.64.6)
using GdkPixbuf version 2.40.0 (compiled against version 2.40.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.44.7 (compiled against version 1.44.7)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> GEGL-WARNING: build program failure
<kernel>:190:7: error: invalid argument type 'const __global float *' to unary expression
  if (! aux)                                                                  
      ^ ~~~



Stack trace:
```

# Stack traces obtained from PID 6804 - Thread 6804 #

[New LWP 6806]
[New LWP 6807]
[New LWP 6808]
[New LWP 6809]
[New LWP 6810]
[New LWP 6822]
[New LWP 6823]
[New LWP 6824]
[New LWP 6825]
[New LWP 6826]
[New LWP 6827]
[New LWP 6828]
[New LWP 6846]
[New LWP 6871]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffd720e71c0, fd=30) at ../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id                                      Frame 
* 1    Thread 0x7fbd20b45340 (LWP 6804) "gimp-2.10"   __libc_read (nbytes=256, buf=0x7ffd720e71c0, fd=30) at ../sysdeps/unix/sysv/linux/read.c:26
  2    Thread 0x7fbd2066e700 (LWP 6806) "worker"      syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3    Thread 0x7fbd1fe6d700 (LWP 6807) "worker"      syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4    Thread 0x7fbd17fff700 (LWP 6808) "worker"      syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5    Thread 0x7fbd1e4d9700 (LWP 6809) "gmain"       0x00007fbd219b2aff in __GI___poll (fds=0x560bb18e5440, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  6    Thread 0x7fbd1dcd8700 (LWP 6810) "gdbus"       0x00007fbd219b2aff in __GI___poll (fds=0x560bb1915c00, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  7    Thread 0x7fbcfd74e700 (LWP 6822) "gimp-2.10"   0x00007fbd219b2aff in __GI___poll (fds=0x560bb1dcf010, nfds=5, timeout=100) at ../sysdeps/unix/sysv/linux/poll.c:29
  8    Thread 0x7fbcf7fff700 (LWP 6823) "gimp-2.10"   futex_abstimed_wait_cancelable (private=<optimized out>, abstime=0x7fbcf7ffe6f0, clockid=<optimized out>, expected=0, futex_word=0x7fbcf0000b88) at ../sysdeps/nptl/futex-internal.h:320
  9    Thread 0x7fbcf77fe700 (LWP 6824) "gimp-2.10"   futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x560bb1a63008) at ../sysdeps/nptl/futex-internal.h:320
  10   Thread 0x7fbcf6ffd700 (LWP 6825) "gimp-2.10"   futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x560bb1a63008) at ../sysdeps/nptl/futex-internal.h:320
  11   Thread 0x7fbcf67fc700 (LWP 6826) "gimp-2.10"   futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x560bb1a63008) at ../sysdeps/nptl/futex-internal.h:320
  12   Thread 0x7fbcf5ffb700 (LWP 6827) "gimp-2.10"   futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x560bb1a63008) at ../sysdeps/nptl/futex-internal.h:320
  13   Thread 0x7fbcf57fa700 (LWP 6828) "gimp-2.10"   futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x560bb1a51a08) at ../sysdeps/nptl/futex-internal.h:320
  14   Thread 0x7fbcf4ff9700 (LWP 6846) "async"       syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  15   Thread 0x7fbcec84a700 (LWP 6871) "swap writer" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

the complete report is in the attached file

[spamegg]

This is a very nice and detailed bug report. It doesn't have anything to do with Mint though. Mint doesn't even come with the 5.14 kernel, or GIMP.

You should probably report it to GIMP developers. https://www.gimp.org/bugs/report.html https://gitlab.gnome.org/GNOME/gimp/-/issues

[michaelhm]

I have reported it there but not sure because it doesn't happened with kernel version 5.13, but let's see what they say

[kc1di]

You should not really install kernels outside of the mint available. 5.14 and 5.13 are not yet supported in any mint version.

[SMG]

You should not really install kernels outside of the mint available. 5.14 and 5.13 are not yet supported in any mint version.

Ubuntu does have a 5.13-oem kernel available. I've had several people switch to it to resolve issues the 5.11 was not able to address.

[kc1di]

You should not really install kernels outside of the mint available. 5.14 and 5.13 are not yet supported in any mint version.

Ubuntu does have a 5.13-oem kernel available. I've had several people switch to it to resolve issues the 5.11 was not able to address.

Wonder why on my 20.2 it only offers me up to 5.11 ? I would assume that 5.13 has not been tested in Mint.

[SMG]

Wonder why on my 20.2 it only offers me up to 5.11 ?

OEM Kernels are not offered through Update Manager. They can be installed using Synaptic Package manager or through the terminal.

[Hoser Rob]

I have reported it there but not sure because it doesn't happened with kernel version 5.13, but let's see what they say

I suspect they'll say the exact same thing. You're using an unsupported kernel for Mint. Case closed.

[michaelhm]

I have reported it there but not sure because it doesn't happened with kernel version 5.13, but let's see what they say

I suspect they'll say the exact same thing. You're using an unsupported kernel for Mint. Case closed.

well, not my shoe what you do, but you get there soon, when nobody would use the new versions there wouldn't be any, also, IMO you could say your opinion in a nicer way

[Hoser Rob]

... not my shoe what you do, but you get there soon, when nobody would use the new versions there wouldn't be any, also, IMO you could say your opinion in a nicer way

If you want the newest everything use a true rolling release distro like Arch, there's very little backwards/forwards compatibility in Linux at all so long term support releases like Mint do not work with too new kernels, and they are not supported by such distros. And no one is paying anyone to be here.

[michaelhm]

If you want the newest everything use a true rolling release distro like Arch, there's very little backwards/forwards compatibility in Linux at all so long term support releases like Mint do not work with too new kernels, and they are not supported by such distros. And no one is paying anyone to be here.

well, I understand your position but do not need to agree with, right? You are thinking in the wrong direction, it is not what I want but what I need, I make another kind of software which runs on Linux and I do not like suddenly getting a cold shower out of the blue, only why I haven't foreseen that, it's me who will suggest the new versions for upgrade together with my software and doing it with tested parts nothing strange will happen, means I am working a couple of month ahead, same as kernel developer do, same as distro developer do, therefor serve the common words like release, stable and head right ... so then I ask you, why the support is always behind?

have a nice weekend

[SMG]

You are thinking in the wrong direction, it is not what I want but what I need, I make another kind of software which runs on Linux and I do not like suddenly getting a cold shower out of the blue, only why I haven't foreseen that, it's me who will suggest the new versions for upgrade together with my software and doing it with tested parts nothing strange will happen, means I am working a couple of month ahead, same as kernel developer do, same as distro developer do, therefor serve the common words like release, stable and head right ... so then I ask you, why the support is always behind?

What support do you think is behind? Linux Mint does not support GIMP. Linux Mint also does not support mainline kernels.

You are using a combination few other people use. While that may be necessary for what you are doing, that means the pool of people who might have a need for a fix you believe is needed is quite small. With the current resource availability, the problems that fall inside the scope of the project and are affecting more people are likely to get higher priority. Two segments of what you are using (GIMP and mainline kernels) fall outside the scope of the Mint project.

This forum is a place where users of Mint help other users. We are able to give support on software installs similar to what we personally use. You have a specialized situation, but maybe someone else will be using the same combination you are and will post.

[motoryzen]

... so then I ask you, why the support is always behind?

Is that directly about Mint? If yes, then you should direct that question to Clem and his dev team *shrugs*.

I've seen when Hoser made a rude comment before, but he didn't make one earlier in this topic btw...just stating the facts. It is a fact that we are all volunteers here ( I could be wrong about a couple at most but by in large...) and overall we're not here to speak to anyone as if he or she is a little 5 year old in Kindergarten ( meaning nice to a very babying extent). That's the only point Hoser was really trying to make in a summarized tone, no insult meant *shrugs*

But the moderators here also are very active on ensuring there is reasonable peace on this site and also have no problem putting the foot down as needed.

Your wanting Mint to be as bleeding edge as the Arch world is( in terms of an Update Manager-included newest kernel) ....isn't a priority for Clem and the rest of the Mint dev team..never has been either. Mint has always focused more on stability ( but not to the - what some would say - gutless-ridiculously safe extent that LMDE is still and has proven to be for years) over bleeding edge-new Kernels/etc. This is one of the many reasons why Mint has really established itself VERY well as one of the top 3 or 4 windows-to-Linux transitional options for the past probably 10 years straight. It's less possible nonsense at the core to worry about.

It's not that Hoser was trying to be rude by shooting down your hopes in that Mint would have a closer-to=Arch-available kernel that is meant to work with it as of the time of typing this comment 10-22-21. It is just a fact that Mint...isn't....Arch, and chances are it never will be.

5.11.x-x is, as of today's comment, the newest available Kernel through the Update Manager that IS/was built/dealt with by Clem and the dev team TO work properly with Mint in every reasonably-accurately-detectable way.

-== Given that Clem and the Mint team have never, don't currently, and probably won't ever be involved directly in developing/maintaining/maintenacing/etc GIMP...that isn't their fault and technically not their problem/responsibility to ensure it works or works to the extent you need.

I have reported it there but not sure because it doesn't happened with kernel version 5.13, but let's see what they say

I noticed that sometimes one Linux distro may illustrate a particular problem with a specific kernel version while another distro works perfectly with it...even if the different distro is still using the same package manager AND is also Ubuntu and/or Debian based. Why? I honestly don't know. But, you may consider trying another distro with that similar version of GIMP to see if the problem is still there.

You may want to consider trying Manjaro out as it is Arch based ( and most often I have personally see it come included with either a newer kernel than Linux Mint..OR the AUR has an even newer one that the Arch and Manjaro devs have confirmed is rock solid stable AND still newer than what is available stock with Linux Mint.

=== Sorry I couldn't be of any real help, but just explaining the facts ---

[Hoser Rob]

If you want the newest everything use a true rolling release distro like Arch, there's very little backwards/forwards compatibility in Linux at all so long term support releases like Mint do not work with too new kernels, and they are not supported by such distros. And no one is paying anyone to be here.

well, I understand your position but do not need to agree with, right? You are thinking in the wrong direction, it is not what I want but what I need, I make another kind of software which runs on Linux and I do not like suddenly getting a cold shower out of the blue, only why I haven't foreseen that, it's me who will suggest the new versions for upgrade together with my software and doing it with tested parts nothing strange will happen, means I am working a couple of month ahead, same as kernel developer do, same as distro developer do, therefor serve the common words like release, stable and head right ... so then I ask you, why the support is always behind?

have a nice weekend

More belligerent ignorance. ACTUAL developers (I've lost count of all the faux devs here) know exactly why Mint doesn't get new software in its repos.

[michaelhm]

This forum is a place where users of Mint help other users. We are able to give support on software installs similar to what we personally use. You have a specialized situation, but maybe someone else will be using the same combination you are and will post.

well, that sounds good but then it isn't as good as it sounds when you get told to shut up

kernel 5.14 I don't consider bleeding edge, it is a release, but I am not here for word-hacking, I just posted about a problem and now it's about me and what I should do and changing the distro, I posted it here because the gimp guys are working at a complete new release (3.0) and probably they don't care about this bug, they are far ahead, whatever, now I shut my box down and wish you all a nice weekend