Arch Linux User Repository

Btw, this bug was reported (tersely) by Klaus Ethgen to the FVWM mailing list (fvwm@fvwm.org) on July 30. I even saw that post at the time, but somehow didn't make the connection to the symptoms I was seeing.

If you follow the threads mentioned in Klaus' email you can learn a lot more about its history. It evidently was affecting a few other WMs as well.

@anne The simplest recipe I found for demonstrating the bug is to just to run pinentry-qt from the commandline of an xterm which is running under fvwm, and then give it the "getpin" command, i.e.

$ pinentry-qt
OK Pleased to meet you
getpin

On my system, doing the above pops the QT dialog window, and you can then type into that dialog window, and after you hit <cr> in the dialog window, focus returns to the xterm window, and you have normal keyboard interaction with the xterm. But the mouse is completely dead: No pointer is visible and button presses do nothing. Only way out that I found was via SIGUSR2 or SIGKILL.

@anne What you say makes sense, if the X server had been started while the "old" (upgraded) libX11.so was still in /usr/lib: In that case, just restarting fvwm while leaving the X server (Xorg) running would not be expected to load the "new" (downgraded) libX11.so into the dynamic cache. Restarting Xorg would bring in the new libX11.so. So that makes sense.

Fwiw: This issue was fixed in fvwm3-git about a month ago, in this commit:

https://github.com/fvwmorg/fvwm3/commit/5c17c83df4605d2d97999740cf180af983298896

However, the fix apparently hasn't yet made its way into "plain" fvwm3-1.0.X.

I tried fvwm3-git with my existing fvwm-2.6.9 config setup, and to my delight, it worked right out of the box. No behavioral differences observed (yet!) from fvwm2. The only mod needed was to change the name of the fvwm executable in .xinit to fvwm3 instead of fvwm. So if you're willing to take a shot at doing that, you may end up as I did with a working setup sans this bug and a "free bonus" upgrade to fvwm3 as well.

My FvwmEvent module (that updates icons and other styles) now works too. For now, I've added libx11 to "IgnorePkg" in /etc/pacman.conf, though I hope a real fix will become available eventually.

@grepfor, I'd be curious to know what your "simpler conditions" for reproduction were. Did they involve turning off icons? Because with respect to your question as to why other window managers are unaffected, I believe that most of them use taskbars, not icons that can be placed anywhere on the screen.

@grepfor Downgrading libx11 and then restarting only fvwm didn't work, but restarting Xorg seems to fix the problem in fvwm. At least, I removed "Style * !Icon", got icons, and the window manager is still running normally. Next, I will try re-enabling my dynamic icon controls in my homegrown FvwmEvent module.

@bidulock Sorry about the delay. I've switched to fvwm-git (2.6.9.r8.g527ea301-1) , and it has the same problem. I'm going to switch back, and then try the libx11 downgrade.

@anne Seeing similar hang symptoms on my setup, running 2.6.9-3, but was able to reproduce under simpler conditions than the ones you describe. Eventually bisected it to this update:

 libx11-1.8.1-2 -> libx11-1.8.1-3

which occurred around July 6. So that would be consistent with your observation that it broke for you after your July 15 update.

Simply downgrading libX11 to 1.8.1-2 fixed it for me, suggest trying that. (Downgrading should be harmless in other respects.)

However, it still leaves open the interesting question of why that seemingly-benign libx11 upgrade interacted badly with fvwm 2.6.9-3, yet nobody else is reporting issues with other window managers. [FYI: The libx11 upgrade simply removed the --disable-thread-safety-constructor option from the PKGBUILD].

If you do try the libx11 downgrade as described above, please post a comment here with the results, so I can file a more informative git issue on it. Thanks!

FYI: I have not tried fvwm-git.

@anne there have been some recent bugfix commits, did you try fvwm-git from the AUR to see if it has the same problem?

fvwm now breaks badly if "Style * !Icon" is not specified - that is, attempting to use icons causes fvwm to hang hard (or block - either way, it requires "kill -9"). The symptom is that it appears to start okay, but if I invoke a function that fires up a bunch of windows in rapid succession, the window manager stops responding: moving the mouse no longer changes the window focus, and clicking on the window frame or on the background no longer has any effect. I debugged this by running with the supplied default configuration (which works fine), and commenting out lines until I was able to isolate the one line whose removal breaks everything.

This happened on July 15, after an O/S update (the previous O/S update was done on June 19). My notes show that I had originally installed fvwm from the main repositories, but it no longer exists there, so I installed this AUR version (2.6.9-3) in the hope that it would solve the problem, but it had no effect.

I'm not finding anything about this on the fvwm forums, but those seem now to concentrate on version 3. Any ideas?