fvwm3 icon indicating copy to clipboard operation
fvwm3 copied to clipboard
verified publisher icon fvwmorg

Fvwm3 becomes partially unresponsive after a few hours

Open hlein opened this issue 11 months ago • 5 comments

Thanks for reporting your bug here! The following template will help with giving as much information as possible so that it's easier to diagnose and fix.

Upfront Information

Please provide the following information by running the command and providing the output.

  • Fvwm3 version (run: fvwm3 --version)
fvwm3 1.1.2 (released)
with support for:  XPM, PNG, Shape, XShm, SM, XRandR, XRender, XCursor, XFT, XFixes, NLS

Plus fvwm-crystal-3.7.6

  • Linux distribution or BSD name/version Gentoo Linux

  • Platform (run: uname -sp) Linux AMD Ryzen 9 3900X 12-Core Processor

Expected Behaviour

What were you trying to do? Please explain the problem.

fvwm3 stays functional and stable and awesome for months (I am an fvwm user since 1.x in the mid-90's, left for i3 maybe 6 months ago to get a continuous multi-monitor display where each one has its own virtual desktops; happily back after learning that DesktopConfiguration per-monitor is a thing now)

But...

Actual Behaviour

After running for some hours (less than a day), fvwm enters the weirdest state I think I've seen from a window manager:

  • sliding/sloppy mouse focus still works
  • new windows can still be created by apps (launching an xterm in an existing shell, browser opening a new window)
  • the root window's window-list popup still works
  • FvwmPager (one per monitor because per-monitor is the best thing since computers were invented) can still switch between virtual desktops on a given monitor, both via mouse-click and via keyboard hotkeys
  • Clicking a window raises its Z-order to top

But...

  • windows can no longer be dragged/moved or resized via the mouse
  • window decoration buttons (maximize, roll up, X to exit) no longer have any effect
  • other popup menus (my primary app menu is on left mouse; right mouse is just "pop an xterm") do not work
  • Restarting (menu no longer works, but FvwmCommand Restart) will end up crashing the X session

This has happened maybe 3 times in the last 2 days. I can't trigger in on-demand, but it will happen eventually.

Enabling logging

fvwm3 has a means of logging what it's doing. Enabling this when reproducing the issue might help. To do this, either change the means fvwm3 is started by adding -v as in:

fvwm3 -v

I have not tried this yet. My display-manager launches the window manager with >/dev/null, although stderr does get captured in ~/.xsession-errors. I haven't noticed anything unusual getting written there.

or, once fvwm3 has loaded, send SIGUSR2 as in:

pkill -USR2 fvwm3

I will try this after creating this bug and add as a comment (given that Restart blows up my session, I worry that touching things will kill my session and the browser I'm writing this in).

The resulting logfile can be found in $HOME/.fvwm/fvwm3-output.log

Steps to Reproduce

How can the problem be reproduced? For this, the following is helpful:

  • Reduce the problem to the smallest fvwm configuration example (where possible). Start with a blank config file (fvwm3 -f/dev/null) and go from there.

I haven't done this yet - my fvwm-crystal setup is fairly stock, except for setting up 4 different FvwmPagers (one per monitor). ...And I've got an ungodly wrapper/launcher to fire up various terminals and browser windows (dedicated profiles for each) that lands them on different specific monitors and virtual desktop row.col. (Maybe there's better ways to do this, but that's another question.)

I'm kind of hoping this rings a bell and the combination of "these things stop working and these things keep working" will narrow things down on what parts must be dying/where to dig in.

  • Does the problem also happen with Fvwm2?

Nothing like this last time I used Fvwm2 - but that was before DesktopConfiguration per-monitor AFAIK.

Include your configuration with this issue.

Does Fvwm3 crash?

If fvwm3 crashes then check your system for a corefile. This is platform dependant, however, check if:

  • corefiles are enabled (ulimit -c)
  • A corefile might be in $HOME or /tmp/.
  • If you're using Linux (with systemd), check coredumpctl list. coredumpctl may need installing separately.

If you find a corefile, install gdb and run:

gdb /path/to/fvwm3 /path/to/corefile

If you're using coredumpctl then use:

coredumpctl debug

Then from within the (gdb) prompt, issue:

bt full

... and include the output here.

Extra Information

  • Anything else we should know?

  • Feel free to take a screen capture or video and upload to this issue if you feel it would help.

  • Attach $HOME/.fvwm/fvwm3-output.log from the step above.

hlein avatar May 20 '25 01:05 hlein

After pkill -USR2 fvwm3 , rather than $HOME/.fvwm/fvwm3-output.log, $HOME/.fvwm-crystal.log got created - something in it is setting $FVWM3_LOGFILE to point to there.

That file got just:

[1747706170.926924]  log opened (because of SIGUSR2)

...And nothing else has been written to it while I move around doing things that both do work (apps launching new windows, moving focus, popping zorder, navigating w/pager) and things that don't (dragging/resizing windows, buttons, etc.).

hlein avatar May 20 '25 02:05 hlein

@hlein

... and if you follow the instruction about attaching gdb to fvwm3, what is it doing?

ThomasAdam avatar May 20 '25 05:05 ThomasAdam

... and if you follow the instruction about attaching gdb to fvwm3, what is it doing?

Good question. It doesn't actually crash/coredump but I'll SSH in from another box and strace, gdb, etc. the running fvwm3 and see what I can see. Then will do an FvwmCommand Restart which does kill my X session when things are in this state (but I don't know that fvwm3 is necessarily crashing there, could be just exiting abnormally).

hlein avatar May 20 '25 15:05 hlein

It doesn't actually crash/coredump but I'll SSH in from another box and strace, gdb, etc. the running fvwm3 and see what I can see.

What I saw was... nothing immediately useful; things were just too noisy. And when restarting fvwm3 it got a bunch of SIGCHILDs, boring-looking ENOENT and EAGAIN errors, and a handful of ECHILD and one single EINVAL on a shmget, and an ENXIO when opening /dev/tty which seems odd.

However... I then did the incredibly smart and useful troubleshooting thing of making two changes at once: 1) switched from fvwm-crystal theme to a bare built-from-stock ~/.fvwm/config, 2) stopped using my script that spawns & places apps on designated monitor+virtual desktop via a combination of FvwmCommand OpenAppOnPage..., xdotool, etc.

And my fvwm3 session has been stable for over a week and counting, where before it would go into this weird state in less than 24 hours. I don't want to reproduce the problem so I'm not reverting either change 1 or 2! But maybe if someone else encounters similar symptoms, this issue will be a starting point.

hlein avatar Jun 19 '25 18:06 hlein

  1. stopped using my script that spawns & places apps on designated monitor+virtual desktop via a combination of FvwmCommand OpenAppOnPage..., xdotool, etc.

Any chance you can attach that script here, please?

ThomasAdam avatar Jun 20 '25 15:06 ThomasAdam

Closing, until further information is given.

ThomasAdam avatar Jun 28 '25 11:06 ThomasAdam

  1. stopped using my script that spawns & places apps on designated monitor+virtual desktop via a combination of FvwmCommand OpenAppOnPage..., xdotool, etc.

Any chance you can attach that script here, please?

Ack, sorry. I don't think I have it any more.

I hacked it up a dozen times probably making it worse each time! Trying different ways to track monitors and layout, active screens/workspaces, launch (create a function that goes to a named page and runs a named command, then call that with FvwmCommand), identify the just-started process via xdotool, xprop, etc. It ended up being a big mess and I wound up trashing most of it when I had to stop using it anyway.

hlein avatar Oct 14 '25 23:10 hlein