A source document was scanned as a grayscale PNG file. It was loaded into GIMP, cropped, and followed by a “Layer » Layer to Image Size” operation. No problems so far (and likely irrelevent - it’s just my typical workflow FWIW). Opened “Colors » Threshold…”. Some images have an interesting graph to help determine where to move the slider and some just have an empty graph. This may not be related but I noticed that both times spaz’d out it was when an image had an empty graph (or nearly empty). As soon as the slider is moved, *both* screens on a dual headed machine go black for ~1½ seconds then pop back on. GIMP is only ever present one of the two displays, never spread out. On one occassion, the system froze for a few seconds before the cursor could move again. On another occasion, the keyboard and mouse were permanently frozen. I walked away from the machine for ~5 minutes or so to give it time to unfreeze, but it never unfroze. I was ultimately forced to physically force a power down of the whole system. It would have been catastrophic if I had unsaved work in any application. GIMP’s tendency to affect other apps also manifests in another way (though less extreme). When GIMP is full screen on one display and emacs is full screen on the other display, if I click on a menu like Colors, leave the menu list open and move the mouse cursor out of GIMP and onto the emacs window, the emacs window takes focus as expected but GIMP fights to keep control of the keyboard. When I type a few keys, the first character appears in the emacs buffer but GIMP seems to react to all keys pressed when emacs is in focus. Emacs only receives the first key but GIMP acts on all keys pressed. When this fight for keyboard control is occurring, both displays go all black for ~1½ seconds before restoring and the mouse is frozen for a second or two after that. Sometimes the GIMP popup window (triggered by the keys pressed in emacs) flickers wildly with different buttons in the window flickering as well. I click cancel to end the madness. So far in that case the system goes back to normal. But the behaviour is similar to when the threshold slider is moved so it appears to be ultimately associated to the same problem. This is on Wayland with Sway running. A similar but different bug was reported here: https://gitlab.gnome.org/GNOME/gimp/-/issues/11275 Paulo Crepaldi called it a “crash” not a freeze, and that was on Windows while my experience was on Debian. These bugs could be related but possibly not. Without more certainty, I did not tag this bug as forwarded upstream. There is also a security problem here. In principle, what if a user were to leave GIMP to enter a password in another app? GIMP should not have access to the keyboard when it is not in focus. This security flaw is not in GIMP, but rather in Wayland or Sway and GIMP is merely demonstrating how an unfocused app can eavesdrop on the keystrokes. The upstream bug tracker blocks registration by pushing a broken CAPTCHA, so I am unable to report this upstream.
Control: reassign -1 sway 1.7-6
Control: retitle -1 sway: whole system froze when adjusting threshold in gimp
It should not be possible for GIMP to achieve this sort of freeze of
the compositor even if it wanted to, so I'm reassigning this to sway
(I've assumed that you're using the version of sway from Debian 12,
please correct the version metadata if that's wrong).
Please check for messages in the systemd journal at the time of this
freeze - I suspect you will see some sort of warning or error from
sway, Xwayland and/or the kernel.
If the compositor (in your case that's sway) gives GIMP access to the
keyboard at times when you think it should not have access, then that's
also not a GIMP bug: it's the compositor that controls what information
is available to applications, not the other way around.
smcv
Hi, * Manny <debbug.gimp@sideload.33mail.com> [2024-06-18 13:13]: I was not able to reproduce this in a debvm, thus lowering severity. What I tried: $ debvm-create -r stable -- --hook-dir=/usr/share/mmdebstrap/hooks/useradd \ --include=linux-image-generic,greetd,sway,sway-backgrounds,suckless-tools,xwayland,gimp \ --customize-hook='echo \'[initial_session]\ncommand = "sway"\nuser = "user"\n[terminal]\nvt = 1\n[default_session]\ncommand = "/usr/sbin/agreety -c sway"\nuser = "user"\' > "$1/etc/greetd/config.toml"' $ debvm-run -g -- -vga qxl That gives me a logged in sway where I can hit Ctrl-D to execute gimp (you can use Ctrl-Alt-G to let qemu grab the key in case it is mapped on your host system.) Then in gimp I created a new image by taking a screenshot and played with the sliders in the Threshold window. To me this bug sounds a lot like a out of memory problem (maybe even out of video memory). Can you have a log at the system log at the time of the crash? Try: sudo journalctl -S 2024-06-18 for that. Also, can you reproduce the bug? Cheers Jochen
I just had another crash, this time with libreoffice-calc. When working on a spreadsheet I get the similar behavior to gimp if I try to change the background color of a collection of cells. Both screens go black. Then the a second later the left display recovers and maybe ½ second later the right screen recovers. The first time it then froze for a few seconds and went back to functioning. The second time this happened, Sway crashed and dumped me in a terminal. All graphical windows were lost but the underlying apps were still running. So if there is anything similar between localc » right cick » format cells » background and Gimp’s threshold dialog, that might give a clue. threshold or localc background color things slow down, the screens blink, and sometimes recover and sometimes crash. Gimp hung and needed a forced power off after the screens blinked. Localc caused sway to crash after blinking the screens. It’s obviously risky to make things crash so I’m not keen to repeat the actions that cause the freeze and crash. When I run journalctl, it looks like a “GPU HANG … Resetting chip for stopped heartbeat on rcs0” might be relevant: ===8<------------------------------ Jul 06 16:35:22 kernel: audit: type=1400 audit(1720276522.925:1405): apparmor="ALLOWED" operation="open" profile="libreoffice-soffi> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:24 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:24 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:30 kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 4:1:9fe7fbfd, in Xwayland [1512] Jul 06 16:35:31 kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 Jul 06 16:35:31 kernel: i915 0000:00:02.0: [drm] Xwayland[1512] context reset due to GPU hang Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="mknod" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="file_lock" profile="libreoffice-soffice" name="~/.config/> Jul 06 16:35:43 kernel: kauditd_printk_skb: 8 callbacks suppressed Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.934:1414): apparmor="ALLOWED" operation="mknod" profile="libreoffice-soff> Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.934:1415): apparmor="ALLOWED" operation="open" profile="libreoffice-soffi> Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.934:1416): apparmor="ALLOWED" operation="file_lock" profile="libreoffice-> Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="rename_src" profile="libreoffice-soffice" name="~/.config/> Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="rename_dest" profile="libreoffice-soffice" name="~/.config/> Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.942:1417): apparmor="ALLOWED" operation="rename_src" profile="libreoffice> Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.942:1418): apparmor="ALLOWED" operation="rename_dest" profile="libreoffic> … Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="mknod" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="file_lock" profile="libreoffice-soffice" name="~/.config/> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="rename_src" profile="libreoffice-soffice" name="/.config/> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="rename_dest" profile="libreoffice-soffice" name="/.config/> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="chown" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:35:55 kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 4:1:9fe7fbfd, in Xwayland [1512] Jul 06 16:35:56 kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 Jul 06 16:35:56 kernel: i915 0000:00:02.0: [drm] Xwayland[1512] context reset due to GPU hang Jul 06 16:36:02 systemd[1391]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE Jul 06 16:36:02 systemd[1391]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'. Jul 06 16:36:02 systemd[1391]: xdg-desktop-portal-gtk.service: Consumed 3.120s CPU time. Jul 06 16:37:14 audit[152923]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:37:14 kernel: kauditd_printk_skb: 12 callbacks suppressed Jul 06 16:37:14 kernel: audit: type=1400 audit(1720276634.754:1436): apparmor="ALLOWED" operation="open" profile="libreoffice-soffi> Jul 06 16:37:14 audit[152923]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:37:14 kernel: audit: type=1400 audit(1720276634.762:1437): apparmor="ALLOWED" operation="open" profile="libreoffice-soffi> Jul 06 16:37:14 audit[152923]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/dc> Jul 06 16:37:14 kernel: audit: type=1400 audit(1720276634.894:1438): apparmor="ALLOWED" operation="open" profile="libreoffice-soffi> Jul 06 16:37:14 audit[152923]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:37:14 audit[152923]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:37:14 audit[152923]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/li> ===8<------------------------------ Since it appears Xwayland Version: 2:22.1.9-1 is tied to the gpu hang, I have attached the info that would be included in an Xwayland bug report. And perhaps this bug should be moved to Xwayland.
* Manny <debbug.1073788@sideload.33mail.com> [2024-07-06 18:41]: [..] I agree, this sounds like a problem in the i915 kernel driver. be from Debian. Can you retry with the Debian bookworm kernel (currently 6.1.94+1)? Cheers Jochen
* Jochen Sprickerhof <jspricke@debian.org> [2024-07-13 11:14]: Kernels version 6+ are a disaster for me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071381 Perhaps I could still try it because the defect in kernels 6+ may take a couple hours to hit. I could probably boot and quickly do the gimp and localc tests before the kernel freeze hits.
I just did a variety of tests with linux-image-6.1.0-21-amd64 booted. The bugs manifesting from gimp and localc certainly are not fixed or avoided in any way. Gimp threshold dialog and localc background color changing both led to severe issues. I tried to change the background on a few cells in localc. Sometimes there was no issue, in which case the screen would very briefly blink black (about as fast as blinking your eyes), and then it would continue functioning fine until the next cell color change attempt. Sometimes the tiled dialog frame (which uses ½ the screen in a Sway) would start flickerly madly. I could close it and hit control-1 try again. I noticed a pattern. If clicking the “color” button in the “background” tab would cause it to go apeshit and I close and immediately retry, it behaves well the 2nd time. So about every other time it would go apeshit. There is a slight difference between the kernels. In kernel 5.x I could go 1 or two steps further. In kernel 6.x, clicking the button literally labeled “color” causes it to go apeshit, blink very slowly (black screens for 1 or 2 whole seconds, followed by a whole system freeze. In kernel 5.x I don’t think clicking the button literally labeled “color” caused any issue, but then when I selected an actual color from the pallet and apply it, then it would go apeshit. Gimp is also a disaster on kernel 6.1.0-21, as with 5.x. But what differs is on kernel 6.x Gimp tended to crash itself without crashing sway, but shortly thereafter the whole system would freeze. On kernel 5.x, Gimp tended to take Sway down with it but without freezing the whole system. One behavior that’s consistent with Gimp on both kernels (5.x and 6.x) and also localc on both kernels is both screens of the 2 headed system would go black for a second or two. Sometimes that’s followed quickly with more severe crashes, and sometimes things continue functioning fine after the blinking. It’s interesting to note that after running kernel 6.1.0-21 and causing several freezes, the journalctl output did not show anything interesting.. no “GPU hang”.