Cage gets stuck calling wl_display_terminate when handling SIGCHLD

[Hjdskes]

I'm implementing support for SIGCHLD in Cage to exit when the primary client either exits without spawning a window or when it crashes.

I already have support for SIGINT and SIGTERM for which I just call wl_display_terminate, which works fine.

When I now call wl_display_terminate upon receiving SIGCHLD, Cage seems to get stuck somewhere (I suspect in rendering) and I have to close the Wayland backend's window for Cage to get unstuck.

I've raised this issue on IRC where @ascent12 mentioned it's likely a wlroots bug, hence this issue. You can view the branch here. The reason I suspect Cage gets stuck in rendering is because I had to fix a segfault in that code, see cage-kiosk/cage@86c5d57 in that branch. I'm testing this against wlroots 0.10.0.

Let me know if there's anything else I can provide of if you need me to try something.

---

wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2012

[Hjdskes]

I should add that Cage uses wl_event_loop_add_signal to handle signals.

[emersion]

Warning, SIGCHLD messes with global state.

You can find out where Cage gets stuck by pressing Ctrl+\. This will produce a coredump from which you can obtain a backtrace.

[Hjdskes]

Thanks. Here's the backtrace obtained from coredumpctl gdb cage after reproducing the hang and continuing with Ctrl+\:

(gdb) bt
#0  0x00007f5eedfd660e in epoll_wait () at /usr/lib/libc.so.6
#1  0x00007f5eee3817c8 in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
#2  0x00007f5eee38039c in wl_display_run () at /usr/lib/libwayland-server.so.0
#3  0x000055a09f637e28 in main (argc=2, argv=0x7ffc681f1298) at ../cage.c:432

---

Warning, SIGCHLD messes with global state.

Can you elaborate on this? What global state?

[emersion]

Hmm, that's not very insightful. The event loop seems to be running as normal.

Can you elaborate on this? What global state?

The handler will steal statuses of processes started by e.g. wlroots. For instance, we do a waitpid call in the Xwayland code. Your handler will make it so wlroots' waitpid call will never receive the process status information.

Instead, maybe you could consider not having a global SIGCHLD handler, and using e.g. a pipe to signal completion?

[Hjdskes]

Hmm, that's not very insightful. The event loop seems to be running as normal.

Woops, just noticed there were no debug symbols for Wayland. Here's a new backtrace:

#0  0x00007f3e649ad60e in epoll_wait () at /usr/lib/libc.so.6
#1  0x00007f3e64d587f9 in wl_event_loop_dispatch (loop=0x55d4c9fca750, timeout=timeout@entry=-1) at src/event-loop.c:634
#2  0x00007f3e64d573d7 in wl_display_run (display=0x55d4c9fd1b00) at src/wayland-server.c:1293
#3  0x000055d4c9c14e28 in main (argc=2, argv=0x7fff57d279b8) at ../cage.c:432

The handler will steal statuses of processes started by e.g. wlroots. For instance, we do a waitpid call in the Xwayland code. Your handler will make it so wlroots' waitpid call will never receive the process status information.

How is that SIGCHLD handler different from the (same) handler for SIGTERM and SIGINT? Does it matter if I waitpid specifically for the pid of the primary client spawned by Cage?

I fully admit not knowing signal handling very well, so I may be asking the obvious.

Instead, maybe you could consider not having a global SIGCHLD handler, and using e.g. a pipe to signal completion?

Do you know of some open source code doing this that I can study?

[Hjdskes]

I think I got something working, but it would be great if you could confirm this is what you had in mind: cage-kiosk/cage@96218dc

After destroying the output layout after the Wayland display (see the parent commit) this seems to work fine!

[Hjdskes]

The initial issue is resolved in Cage by using a pipe rather than SIGCHLD, but I'll leave it up to wlroots developers to decide if this issue should be closed or not.