Strange hang in FVWM 3 ver 1.1.1 #1182
Description
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
META
The hang occurred on 2025 FEB 18. I had earlier reported this in the FVWM forums. Sorry for the delay in logging a proper issue.
I am aware there is a newer release available, but hadn't gotten around to installing in on that laptop at the time. That has since been rectified.
When this happened, I was unaware of the "strace a running process" technique. If it happens again I will do that.
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.
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. (Nothing else was noted in that log.)
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 has been fine since.
AVAILABLE ARTIFACTS
- Screenshot
- GDB backbtrace taken at four different times
- Core dump
- Log files
- fvwm3-output.log
- Xorg.0.log
- xclients.out
- 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
Metadata
Metadata
Assignees
Labels
Type
Projects
Status