Description of problem: I forgot that /usr/bin/import only works on X and executed it on a machine running Wayland which hung the display. I was able to ssh in and kill the import process which released the display, but without ssh access I was unable even to switch to a second console. This behavior seems to me to be to be a bug somewhere in the display system, not ImageMagik, but I don't know what component, so I'm filing it here in the hope that it can be redirected. Version-Release number of selected component (if applicable): ImageMagick-6.9.11.27-1.fc33.src.rpm How reproducible: 100% Steps to Reproduce: 1. import foo.jpg 2. wait a few seconds, in one case it seemed to take almost 20 seconds, in another it hung almost immediately 3. observe display hang I originally experienced this situation when I wedged my laptop (Fedora 32) with no way to ssh in and, after rebooting, was able to reproduce on a fully updated Fedora 33 VM where I could ssh in and verify that it was the display, not the whole machine, that was wedged.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Confirmed still present on fully updated F35. It's 100% reproducible using the steps above. I realize very few people are likely to use import to cause this bug, but there's clearly an underlying problem here that allows a user to wedge the display.
Just hit this again by accidentally sourcing a python file that started with an import statement; my bad, but wedging the display is a really unpleasant bug. I'm changing the component to wayland since IMO the issue isn't with ImageMagick.
Was just able to reproduce this on F36, I'll ask some people to take a look
Wayland really isn't the right component here, Wayland is just the Wayland protocol definitions and has nothign to do with any of this. ImageMagick was probably a better pick, see below. The command "import" is an X11 client and issues an XServerGrab() (something that X11 apps should *never* do, but hey, ImageMagick is old). What XServerGrab() does is to "disable processing of requests and close downs on all other connections than the one this request arrived on" [1]. Basically, that means the X11 client (import, in put case) want to be the only X11 client talkign to the Xserver, preventing all other clients from accessing the screen. You can observe the effect by running another X11 clients (e.g. glxgears), it will stop refreshing when import is started. On Xorg, that works becauset he Xserver is on its own and manages the hardware, including input devices, so gragging the Xserver does not stop the pointer from moving. On Wayland, the design is different though, Xwayland is not the display server anymore, the Wayland compositor is the display server, the one in charge or dealing with input devices. Xwayland is an X11 server, but merely a regular Wayland client. The Wayland compositor is also an X11 client, because in the case of mutter, it is also an X11 window manager. By now, you probably see where I am going here… What happens is the following: 1. import is launched and issues an XServerGrab() 2. Xwayland restrict access to thhat "import" X11 client alone 3. mutter continues to process events until it needs to sync with Xwayland (that's the variability in time before the hang occurs) 4. When mutter does an XSync() (explicitely or implicitely through some other Xlib call), it will wait for Xwayland 5. Xwayland waist for the XServerGrab() to be released by import 6. import waits for a user input to release the the XServerGrab() At that point, the only way to get out of the deadlock is to log in remotely via ssh and kill either import of Xwayland, and normal processing should be restored. So we have here is a perfect example of a deadlock. But we cannot avoid it other than redesigning the whole Wayland stack. Maybe we could just *not* refuse to honor the XServerGrab() requests from anything but the Window manager in Xwayland, that would avoid the issue with broken clients such as this one. [1] https://tronche.com/gui/x/xlib/window-and-session-manager/XGrabServer.html
> Maybe we could just *not* refuse to honor the XServerGrab() requests from anything but the Window manager in Xwayland, that would avoid the issue with broken clients such as this one. I mean, refuse to honor the XServerGrab() requests
Not my area of expertise, but that seems like a reasonable solution.
Test package / scratch build fo F36 here: https://koji.fedoraproject.org/koji/taskinfo?taskID=91664256
I tested that build, and it seems to fix the display hang. I didn't see any problems with it in trivial testing, but I really didn't play with it too long.
Thanks for testing! That first version was a bit crude in the sense that it would prevent *all* X11 clients from issuing server grabs. I have updated the patch to implement what I explained in comment 5, i.e. prevent all X11 clients but the X11 window manager (which may have a valid use case for an Xserver grab). New build here: https://koji.fedoraproject.org/koji/taskinfo?taskID=91691008 As for possible side effects, there is one obviously! "imports" grabs the Xserver to draw a wireframe when selecting an area, and uses logical XOR draws for that purpose. Without a grab, the wireframe does not show, but that's a lesser issue than a complete hang, and btw, selecting areas from X11 cannot work with Xwayland because the root window has no storage, so this operation fails anyhow (regardless of the fix here). As a side note, there are now much better tools to capture the screen content in a Wayland session, GNOME Shell has a neat screenshot/screencast UI built-in nowadays, I really so no reason to use legacy, deprecated X11 only applications such as "import" from ImageMagick for such needs in a Wayland session. So to me this really is a case of "don't do this", but if you really mean to use "import", at least, it won't hang your all session anymore :)
I should have commented that I don't have any need to use import, I just filed the bug because I was concerned about the display wedging.
(In reply to Dave Allan from comment #11) > I should have commented that I don't have any need to use import, I just > filed the bug because I was concerned about the display wedging. And that was definitely the right thing to do, any X11 client issuing a server grab can hang the Wayland desktop the same, so that's definitely much appreciated!
FEDORA-2022-6e1985c485 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6e1985c485
FEDORA-2022-7bc0607f67 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7bc0607f67
FEDORA-2022-7bc0607f67 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-7bc0607f67` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7bc0607f67 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-6e1985c485 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6e1985c485` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6e1985c485 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.