Package: gimp
Version: 3.0.2-3
Severity: normal

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

-- System Information:
Debian Release: 13.0
APT prefers unstable
APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.27-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gimp depends on:
ii gimp-data 3.0.2-3
ii gir1.2-gimp-3.0 3.0.2-3
ii graphviz 2.42.4-3
ii libaa1 1.4p5-51.1+b1
ii libappstream-glib8 0.8.3-1
ii libarchive13t64 3.7.4-3
ii libasound2t64 1.2.14-1
ii libbabl-0.1-0 1:0.1.112-1
ii libbz2-1.0 1.0.8-6
ii libc6 2.41-7
ii libcairo2 1.18.4-1+b1
ii libcfitsio10t64 4.6.2-2
ii libfontconfig1 2.15.0-2.3
ii libfreetype6 2.13.3+dfsg-1
ii libgcc-s1 14.2.0-19
ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-2
ii libgegl-0.4-0t64 1:0.4.58-2
ii libgexiv2-2 0.14.3-1+b1
ii libgimp-3.0-0 3.0.2-3
ii libglib2.0-0t64 2.84.1-2
ii libgomp1 14.2.0-19
ii libgs10 10.05.1~dfsg-1
ii libgtk-3-0t64 3.24.49-3
ii libgudev-1.0-0 238-6
ii libharfbuzz0b 10.2.0-1+b1
ii libheif1 1.19.8-1
ii libjpeg62-turbo 1:2.1.5-4
ii libjson-glib-1.0-0 1.10.6+ds-2
ii libjxl0.11 0.11.1-4
ii liblcms2-2 2.16-2
ii liblzma5 5.8.1-1
ii libmypaint-1.5-1 1.6.0-4
ii libopenexr-3-1-30 3.1.13-2
ii libopenjp2-7 2.5.3-2
ii libpango-1.0-0 1.56.3-1
ii libpangocairo-1.0-0 1.56.3-1
ii libpangoft2-1.0-0 1.56.3-1
ii libpng16-16t64 1.6.48-1
ii libpoppler-glib8t64 25.03.0-4
ii librsvg2-2 2.60.0+dfsg-1
ii librsvg2-common 2.60.0+dfsg-1
ii libstdc++6 14.2.0-19
ii libtiff6 4.7.0-3
ii libwebp7 1.5.0-0.1
ii libwebpdemux2 1.5.0-0.1
ii libwebpmux3 1.5.0-0.1
ii libwmf-0.2-7 0.2.13-1.1+b3
ii libwmflite-0.2-7 0.2.13-1.1+b3
ii libx11-6 2:1.8.12-1
ii libxcursor1 1:1.2.3-1
ii libxext6 2:1.3.4-1+b3
ii libxfixes3 1:6.0.0-2+b4
ii libxmu6 2:1.1.3-3+b4
ii libxpm4 1:3.5.17-1+b3
ii python3-gi 3.50.0-4+b1
ii xdg-utils 1.2.1-2
ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1

Versions of packages gimp recommends:
ii ghostscript 10.05.1~dfsg-1

Versions of packages gimp suggests:
ii gimp-data-extras 1:2.0.4-0.2
ii gimp-help-en [gimp-help] 3.0.0-4
ii gimp-help-it [gimp-help] 3.0.0-4
ii gvfs-backends 1.57.2-2
ii python3 3.13.3-1

-- no debconf information

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On Thu, 15 May 2025 at 12:42:33 +0200, Giacomo Mulas wrote:

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.

...

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?

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.

The weird thing is that it works flawlessly if I simply ssh to localhost before running it.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)