Tangentially related, but for some reason I want to share:
This reminds me of an issue I faced in my own window manager just this week:
On some user actions in some applications that were spawned as children of the WM, the whole X session froze. After attaching gdb to the process, I discovered that it received a SIGTTOU… somewhere in the polling code of libxcb (in case someone isn’t aware: XCB is a library binding the X protocol to C). This could be reproduced in a reliable fashion and seemed rather odd. After some pondering I simply redirected stdout and stderr “away” from the TTY and the issue went away.
It turns out that the browser (a child of the window manager’s process) generated some output that went to the TTY, as it’s stdout was inherited from it’s parent. This, together with the infrastructure starting the window manager (xinit, startx etc.) caused the SIGTTOU to be sent as it normally would be. The fact that the signal was received at the same address consistently across reruns turned out to be simple to explain once I got the right idea: The signal was caused by an application run by the user, which obviously meant that the window manager was waiting for events from the X server at this time, and waiting for the kernel to be woken up after successfull completion of a syscall reading from the UNIX domain socket used to connect to the X server.
That’s how, with a distance of multiple decades, two very similar issues around very similar software are found and fixed.