Strange hang in FVWM 3 ver 1.1.1

Other things FVWM General FVWM discussion
1

SUMMARY

After bringing up a window list, FVWM 3 ver 1.1.1 stopped responding to most everything except SIGUSR2. Core dump available. Any interest in debugging, or just wait and see if it happens again with 1.1.2?

ENVIRONMENT

  • FVWM 3 version 1.1.1 (built from official tarball)
  • Debian 12.9 “bookworm”
  • Kernel 6.12.9+bpo-amd64 / 6.12.9-1~bpo12+1 (2025-01-19)
  • GCC 12.2.0 (12.2.0-14)
  • X.Org 1.21.1.7 (2:21.1.7-3+deb12u8)
  • Lenovo ThinkPad T16 Gen3
  • Intel Core Ultra 7 155U CPU
  • Intel “Meteor Lake-P” graphics, HWID 8086:7D45

BACKGROUND

I normally boot to text console, login, and do “startx”. My .xinitrc starts FVWM and uses that as the session controller for X. When FVWM exits, so does X.

I have been running this build of FVWM on this laptop since 2024 December 20, with no FVWM problems until now.

This X+FVWM session had been started about 12 hours earlier.

I am aware there is a newer release available, but hadn’t gotten around to installing in on this laptop yet.

PROBLEM

I opened a new xterm, maximized it, and then accidentally iconified it. I brought up a window list to get back to that xterm. FVWM hung around that time.

INVESTIGATION

The window list was displayed with the first entry highlighted, but it would not move. No response to most keyboard bindings I could think of. I did not think to try CTRL+ALT+Fx to switch virtual consoles. I did think of, but did not try, CTRL+ALT+BKSPC to kill the X server. FVWM did not respond to the key combo I have bound to EscapeFunc. The mouse pointer did move, but clicking mouse buttons had no effect.

I SSH’ed in from another computer. ps showed fvwm3 as R (running). CPU time counter was increasing steadily. So FVWM was acting like it was busy, even though the graphics were basically frozen.

I tried SIGUSR1 to get it to restart. That had no discernible effect, on screen or in logs.

I tried SIGUSR2 twice, and that did result in “log closed/opened” messages, so FVWM was not completely hung.

I used gdb to dump a handful of backtraces, and they varied with time, so something was still happening inside FVWM. The common ancestor in all was “_menu_loop”.

I captured a screenshot (via SSH and “-display”).

I collected a bunch of random info from utilities like “ps” as well as things in /proc/.

I used gcore to collect a core dump of the running FVWM process.

I sent SIGKILL to FVWM. FVWM exited, taking X down with it. I noticed, after FVWM died but before X shut down, that my iconified xterm did reappear, so that part of X was still working normally.

Once back at the text console, I was able to startx back into my desktop, and it seems fine now.

AVAILABLE ARTIFACTS

  • Screenshot
  • GDB backbtrace taken at four different times
  • Core dump
  • Log files
    • fvwm3-output.log
    • Xorg.0.log
  • Output of various commands
    • fvwm -V
    • “lsof” against FVWM process
    • “procinfo.py -v” against FVWM process
    • Several different “ps” invocations
  • Copies of several files from /proc/$(pidof fvwm3)/
    • maps
    • mountinfo
    • mounts
    • mountstats
    • numa_maps
    • smaps
    • stack (notably empty)
    • stat
    • statm
    • status
    • syscall
    • wchan
    • io (over time)
    • sched (over time)
  • Copy of installed FVWM binaries
  • Copy of source tree used to build said binaries

CONCLUSION

I understand there is not sufficient time to chase every random weird problem. I also understand if you want to reserve debugging efforts for the latest release. But if you want to look into this, I’m happy to provide what I can. Please let me know either way.

2

Hi @DragonHawk

Thanks for this detailed report – but you are much better off logging this as an issue on Github:

So that I can track it there.

My initial thought here is that next time fvwm3 hangs, immediately attach strace to it:

strace -s0 -ff -p <PID> -o /tmp/fvwm3-strace.out

So that we can see where in its event loop things are hanging.

I suspect this could be more of an X11 problem though, but strace would confirm that. For strace to be useful, you’d need to ensure you’re building fvwm3 with debug symbols.

Kindly,
Thomas

3

Hi, thanks for the quick reply.

much better off logging this as an issue on Github:

This post began as a quick “Hey is this worth reporting?” question and kind of snowballed into a complete bug report, so… yeah. :) I’ll open up the GitLab Issue.

I’ll add that strace command to my bag of tricks, thanks for that.

ensure you’re building fvwm3 with debug symbols.

I’m building with Mason with the defaults. I’m not stripping the binary. Do I need to do anything else? Mason is new to me.

4

Hi @DragonHawk

No problem at all! As for meson… yeah, as you have it now should be fine.

Let me know how you get on – and thanks for opening an issue on GH.