Bug 2158562 - X11 server stops generating mouse events and has other problems if a Tk program opens two iconified windows on startup
Summary: X11 server stops generating mouse events and has other problems if a Tk progr...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: libX11
Version: 37
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: José Expósito
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2023-01-05 18:16 UTC by Chris Siebenmann
Modified: 2023-08-31 14:22 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Chris Siebenmann 2023-01-05 18:16:45 UTC
Description of problem:
I just upgraded from Fedora 36 to Fedora 37 and now when I start my exmh (a TCL/TK based program) on one of our Ubuntu 22.04 LTS servers via a 'ssh -X' session, my local X server appears to very soon stop sending mouse events to any X program. This state persists even if the remote exmh is terminated, or I kill my local window manager (a custom built version of fvwm2). Keyboard events continue to be received and processed by the window with focus (such as an xterm), if it has focus at the time that mouse events stop being processed. I checked this with xev, which doesn't receive focus or report mouse events over it, such as button clicks.

When the remote exmh starts, its windows are incompletely rendered. My exmh normally starts iconified, and when this happens I see only one of two iconified windows, and the icon area is gray instead of rendered with anything.

I am using an AMD Radeon RX 550 graphics card on dual 4k HiDPI monitors, with the normal Fedora drivers (not the binary proprietary AMD driver). I can't see any error messages or unusual messages in my session log or, in the systemd journal, or basically anywhere I've looked.

I welcome suggestions of either ways to inspect and debug the system in this state or ways to reset the X input system and see what is going on.

Version-Release number of selected component (if applicable):

kernel 6.0.16-300.fc37.x86_64

How reproducible:
100% for me.

Steps to Reproduce:
1. ssh -X to our server
2. start exmh
3. wait a bit and see everything explode

Comment 1 Chris Siebenmann 2023-01-05 18:38:27 UTC
Further investigation suggests that this is some kind of X server based grab in action. If I run xwininfo it will report that it can't grab the mouse, and even if I kill various X programs the X server doesn't update the display to remove their windows. I found some suggestions online for how to break a grab, but they didn't seem to change anything ('setxkbmap -option grab:break_actions; xdotool key XF86Ungrab').

Using 'xinput --query-state' on my mouse pointer shows that xinput is seeing appropriate mouse buttons going down and up; if I have a mouse button pressed, it will show as 'down'.

Comment 2 Chris Siebenmann 2023-01-05 21:24:58 UTC
I have now managed to reduce this to a minimal test case that works locally. If you run a TCL/Tk program that creates two iconified windows on startup, things go wrong in the X server (provided, it appears, that your window manager configuration is making them into actual X icons, as my fvwm configuration is). One of the things that goes wrong is the event handling, although it's not as simple as a grab. If I park my mouse cursor over an xterm window when I start this, the window continues to receive mouse-1 button presses (which aren't intercepted by anything). However, once mouse button events would be handled or intercepted by something else (including fvwm because it has bindings for mouse-2 + modifiers), and even mouse movement events for entering and leaving windows, clients stop seeing them.

(This doesn't seem to reproduce in a virtual machine using the standard Fedora fvwm and its default configuration, but that fvwm configuration swallows iconified windows into side buttons, instead of leaving them as real X icons.)

The test program:

wm title . "iconify example"
pack [button .b2 -text "exit" -command exit]
wm iconposition . 500 500
wm iconify .

toplevel .sec
pack [label .sec.l -text "This is a label"]
pack [button .sec.ok -text "OK" -command {puts "OK"}]
wm title .sec "Another icon"
wm iconposition .sec 600 600
wm iconify .sec

Comment 3 Chris Siebenmann 2023-01-05 22:27:00 UTC
By selectively reverting packages to the Fedora 36 versions, I have narrowed this down to libX11 instead of the X server. With only the libX11 packages reverted to Fedora 36, I can't reproduce this (either with my test program, or with a window manager script that resets the positions and states of all of my Firefox windows, which results in a flurry of iconified windows and also locked up). I did the reverts with 'dnf --releasever 36 distro-sync libX11 libX11-xcb', basing this on what shared libraries the X server was using. I've updated the component (I hope) to correspond to this.

Comment 4 Peter Hutterer 2023-01-06 04:26:29 UTC
I just built libX11 1.8.3 which has some fixes for the XInitThread change. My best *guess* right now is that it may be related to that. Can you try those packages please and see if it fixes the issue? Thanks.

koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=95790987
bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a9ae939de3

Comment 5 Chris Siebenmann 2023-01-06 17:10:50 UTC
So far this libX11 1.8.3 passes my test cases, both the reproduction in the previous comment and another case I found (where a scripted sequence of rapid window manager iconifications and deiconifications of my Firefox windows would reliably hang). It also doesn't seem to be creating any new problems in my X session that I've spotted so far.

Comment 6 Chris Siebenmann 2023-01-06 17:49:45 UTC
Unfortunately I spoke too soon. Longer use of my X session triggered failures. I saw core dumps in my fvwm, with the message 'fvwm: xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed.', and anomalies in the X server itself after fvwm failed, where keyboard focus would not follow the mouse properly. (When my fvwm dies normally, I can transfer focus to an existing terminal window to restart it.)

Comment 7 Chris Siebenmann 2023-01-15 19:09:42 UTC
With the help of Thomas Adam of fvwm, I found a simple reproduction for the initial bug. Take a Fedora 37 (libvirt) virtual machine and put the reproduction in your home directory as eg 'icom-boom.tk'. Then:

* install the fvwm and xterm packages
* arrange to get an empty fvwm configuration with 'mkdir .fvwm; touch .fvwm/config'
* log out and log in as a fvwm session, which will give you a black screen
* use the left mouse button to get the default fvwm menu
* start an xterm
* in the xterm, run icon-boom.tk

This should create two root window icons toward the lower right; instead you'll get one gray rectangle and the fvwm menu will stop responding. If desired you can run xev before hand so you can see what events it does and doesn't get after the failure.

Comment 8 Peter Hutterer 2023-01-16 05:14:32 UTC
there was a bug on the 1.8.3 release, now fixed with libX11-1.8.3-2. Can't promise it'll fix your issue, but it's worth a try (and just a dnf update away :)

Comment 9 Chris Siebenmann 2023-01-18 18:59:10 UTC
Unfortunately libX11-1.8.3-2 still has problems. While things don't explode immediately, the X server got itself into some kind of anomalous situation where not only did fvwm crash, but restarting fvwm caused it to immediately crash on startup again, and while things sort of worked for a while without fvwm, eventually mouse events appeared to stop reaching programs like Thunderbird so I could no longer shut them down in an orderly way.

Comment 10 Bill Perkins 2023-01-19 17:13:29 UTC
I may be seeing this problem from a different point of view.  I am running FVWM on Fedora-37 just fine, but with only this one problem: the mouse and keyboard will occasionally stop being able to input to the GUI.  I can still switch to the VT screens (ctrl-alt-f2), and kill the window manager with 'killall -9 fvwm' in order to get back to a login screen and restarting my session.  The problem generally seems to occur when I am messing around with desktop icons.  An example of which is the see the input session freeze when I expand an icon to reopen an application window.  The icon expands to the fully open window, but then all input is disabled.  A shadow of the opened icon sometimes remains on the desktop after the freeze.  This problem generally happens once every few days and it does not matter to which applications the icons may belong.  The problem may happen with any of them.  I may try reverting libX11 to the Fedora-36 version and see what happens.  I hope I do not break anything in doing so.

Comment 11 Bill Perkins 2023-01-24 02:55:32 UTC
To expand on Comment 10: On the twentieth, I did revert the installed libX11 packages from fedora-37 (1.8.1-2) to the fedora-36 (  All problems and issues that I previously had running the FVWM window manager within fedora-37 did not reoccur.  I have not yet seen any updates of the libX11 packages in the repositories, so I guess that there is, as of yet, no fix for the problem.  One way that I have found to demonstrate the problem is to run the mate-appearance-properties (mate-control-center-1.26.0-5.fc37.x86_64.rpm) program and then do a restart of the FVWM window manager from the control menu.  The window manager hangs every time.  You then have to go to a tty terminal to kill FVWM and login to start your session all over again.

Comment 12 Peter Hutterer 2023-02-08 02:53:44 UTC
libX11 1.8.4 is out now with what looks like a related fix. maybe this time?

Comment 13 Chris Siebenmann 2023-02-09 21:34:27 UTC
A (slow moving) status update: after I tried libX11 1.8.3-2, I wound up trying out fvwm3 and then migrating from fvwm2 to fvwm3. Fvwm3 specifically contains fixes for the libX11 1.8.x change, and it's the only version of fvwm that is still being developed upstream as far as I know. Contrary to my belief that the issues were partly in the X server, not just in fvwm, my environment is now stable (on 1.8.3-2 and 1.8.4); if the X server is having some problem with 1.8.x, it's not noticeable to me.

It's possible that 1.8.4 fixes the problem with fvwm2, but I'm not really going to be able to tell. Possibly @wmp will be able to test it in their fvwm2 environment. Based on the description, I think it may be the same root problem (manifesting in the normal Fedora fvwm session environment where the window manager exiting ends the session, which is not my setup).

The good news (such as it is) is that I'm running with 1.8.4 and it seems to work fine; everything works, there are no visible glitches, and so on. So maybe it's safe to ship as an update that probably improves the situation and fixes bugs in general, or release to testing.

Comment 14 Bill Perkins 2023-02-18 19:43:52 UTC
Well, I have updated my Fedora-37 workstation version of libX11 from to 1.8.4-1 and have experienced no more loss of keyboard and mouse inputs during my FVWM X sessions. The libX11 1.8.4-1 version seems to work fine with either FVWM2 or FVWM3 (1.0.6a) with the following glaring (for me) exception: Whenever I do an in-place restart selected from the regular menu or from the control menu, I get kicked back to the X login screen and lose my current session. This is a bit of a nuisance, because I am currently rewriting my FVWM configuration to work more correctly with the new version three of FVWM. I need to do the in-place restart of FVWM so as to test my changes as I make them.  So, I will be going back to libX11 until I either finish my new configuration tests or this indicated problem get fixed.  Hopefully the latter!

Comment 15 Stefan 2023-03-14 16:14:32 UTC
Just fyi, i am using Devuan (a debian fork without systemd) and I have the same occasional fvwm crashes with this message:

fvwm: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed.

I start X manually from console with startx and i can trigger the fvwm crash by clicking /minimizing maximizing/resizing windows for some seconds.

I have modified my xinitrc file to not exit when fvwm crashes so i can switch to console and run another fvwm. 
Without this i can no longer use the system with fvwm.

The fvwm crash happens also without any tcl-tk app running at all.

All these problems happened after a xserver-xorg update to 21.1.7-1

Comment 16 Stefan 2023-03-14 23:07:21 UTC
My problems with fvwm2 crashes were all fixed by downgrading libX11 and libX11-xcb1 to 1.8.3. 
Other users had the same regression with libX11 1.8.4


Don't know if all this applies also to Redhat, but the bug described here helped me to narrow down the problem and work around it.

Note You need to log in before you can comment on or make changes to this bug.