dwm hangs on ctrl+z-like hotkeys

[myrrc]

Hi!
Not quite confident what's the cause, or whether the cause is related to dwm,
but maybe you could give me a hint. I'm using dwm (latest master) with the
following patches:

git diff --no-color origin/master -- patches.def.h | grep +#define
+#define CENTER_TRANSIENT_WINDOWS_PATCH 1
+#define COOL_AUTOSTART_PATCH 1
+#define DECORATION_HINTS_PATCH 1
+#define LOSEFULLSCREEN_PATCH 1
+#define NOBORDER_PATCH 1
+#define TOGGLEFULLSCREEN_PATCH 1
+#define MONOCLE_LAYOUT 0

The following key bindings are defined:

alt + asdf - focus monitor
win + asdf - move to monitor
alt + g - spawn dmenu
alt + enter - spawn st
alt + r - spawn maim
alt + k - cycle focus previous window in stack
alt + j - cycle focus next window in stack
win + shift + q - kill client
alt + e - toggle floating
alt + m - toggle fullscreen

As a terminal emulator I use st (also latest master) with the following patches:

+#define BOXDRAW_PATCH 1
+#define CLIPBOARD_PATCH 1
+#define COPYURL_HIGHLIGHT_SELECTED_URLS_PATCH 1
+#define DYNAMIC_CURSOR_COLOR_PATCH 1
+#define HIDECURSOR_PATCH 1
+#define KEYBOARDSELECT_PATCH 1
+#define LIGATURES_PATCH 1
+#define REFLOW_PATCH 1
+#define SIXEL_PATCH 1
+#define WIDE_GLYPHS_PATCH 1

My main use case of st is launching it with /bin/bash, spawning some processes
and suspending them via Ctrl+z. Sometimes, possibly when I mis-press Ctrl+z,
dwm hangs with the following pattern:

• terminal window stops being re-drawn and instead gets filled with background
  color only. It doesn't react to any input, including killclient,
  image of how it looks: https://ibb.co/wMB0S66.
• When I re-focus to other terminal windows, they also stop being redrawn.
  At this point, killall st launched from dmenu sometimes helps -- all
  terminals are killed, but other windows become fully functional.
• If I try to launch st with /bin/sh or xterm with any of these two shells,
  only a background color is drawn, no reaction to input.
• Other windows like Telegram or Firefox remain functional for a while, but
  after some time they also degrade to (1). At this point neither killall dwm
  or killall Xorg work, the only option is to restart the computer.
  They don't "work" in the sense the login window isn't shown, but rather just
  a blank screen with a cursor.
• What's strange is that after (4) switching to other TTY (Ctrl+Alt+F3-4-5)
  doesn't work either.

I suppose it's dwm and not an st issue as, afaik multiple st instances don't
share anything so issue with one st wouldn't affect other applications.
I've tried building and launching dwm with debug info, killing it to generate a
coredump, and changing xsessions file to redirect dwm log, but no useful info
was found.

OS: Debian 13 trixie
Xorg: 1:7.7+23.1
Login manager: none, x11 is started in .bash_profile:

[[ -z $DISPLAY ]] && exec startx

[bakkeby]

Hi @myrrc,

that is an impressive amount of detail in your summary.

This doesn't sound like any issue I am familiar with, but it does remind me of the times when I have tested out command line flags for picom for example and have accidentally suspended the compositor by hitting Ctrl+z putting it in the background.

This does most likely not have anything to do with dwm itself, because besides having very few patches the window manager does not have anything directly to do with the actual drawing of the window content (it just handles window placement and restrictions and the like).

As such I think that this may be a compositor issue.

With the lack of a compositor I believe the drawing may fall back to the X server.

That you run startx in your .bash_profile is suspicious, but I don't see any good reason why that should not work or interfere for that matter.

My recommendation would be to install Xephyr and try to run your dwm through that, spawn some terminals and see if you can reproduce the issue through that. Xephyr is a tool that lets you run a separate X11 session inside a window and can be quite useful to test and try things out.

---

(* in dwm of course the window manager handles the drawing of the bar)

(** on the Wayland side compositing and everything else must also be handled by the window manager)