Dear Maintainer,

The present version of gimp on startup first hangs, then crashes _when running in a gnome session on Wayland.
It happens also on a freshly created new account, to make sure there are no funny accumulated, old configurations in my gnome session causing the problem.
The weird thing is that it works flawlessly if I simply ssh to localhost before running it.
Playing with differences, I eventually found out that if the environment variable GTK_MODULES is set to contain the module "appmenu-gtk-module", then gimp crashes. If it does not contain it, it starts flawlessly.
I hope this helps tracking and solving the problem for good. For the time being, I can just work around it by unsetting GTK_MODULES before starting gimp.
By the way, where is "appmenu-gtk-module" appended to the GTK_MODULES variable?

Thanks, best regards
Giacomo Mulas

Control: retitle -1 gimp crashes on startup in GNOME Wayland session if appmenu-gtk-module enabled
Control: reassign -1 gimp,appmenu-gtk-module
Control: found -1 gimp/3.0.2-3
...

gimp and its direct dependencies are not responsible for requesting
appmenu-gtk-module. It appears to be appmenu-gtk-module.service in the
appmenu-gtk-module-common package that does this:
https://sources.debian.org/src/appmenu-gtk-module/25.04-1/data/appmenu-gtk-module.service.in/

GTK modules execute arbitrary code in every GTK 3 process, so if there
is any bug in either the appmenu-gtk-module code or its interactions
with some specific app like gimp, it can easily cause a crash.

Can you get a backtrace from this crash?
(See https://wiki.debian.org/HowToGetABacktrace, usually the easiest way
is to use the systemd-coredump package)

Are other GTK 3 applications like the ones in the gtk-3-examples package
affected by this crash?

Looking at the appmenu-gtk-module source code, I see that it interposes
itself into the GTK code by overwriting GTK classes' internal function
pointers. This is the sort of thing that can very easily cause crashes
when an internal implementation detail of GTK or the app changes, which
is a large part of why GTK 4 no longer supports arbitrary loadable
modules.

I wonder whether the logic in appmenu-gtk-module.service might be
accidentally removing appmenu-gtk-module from the GTK_MODULES passed to
D-Bus-activated services as a side-effect of logging out from the ssh
session?

     smcv

Thanks for the data!

It looks like this is a general issue somewhere between GTK+ 3 and that
appmenu-gtk-module and has nothing to do with either Debian or blueman
specifically.

I could easily reproduce it in a Manjaro VM by running Wayland and
starting either of the following applications with the module enabled:

* blueman
* gimp
* transmission-gtk (version 3, as 4 uses GTK 4)

The traces show an insane stack of gtk_css_node_ensure_style frames.
There are probably many more GTK+ 3 applications out there, that can
trigger the issue, but, supposedly, it depends on some specific structure.

References:

https://gitlab.gnome.org/GNOME/gimp/-/issues/11564 for GIMP

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036775 for transmission

While the cause is most probably somewhere in that appmenu-gtk-module, I
can image that
https://gitlab.gnome.org/GNOME/gtk/-/commit/fc823eb61002d1350305cba6ec718a7c4f6c05e1
covered it, so that GTK 4 is not affected by the crashes.

Workarounds include excluding appmenu-gtk-module from GTK_MODULES or
setting GDK_BACKEND=x11.

Regards