Conversation
font_pango triggers creation of a glib thread which might capture SIGCHLD from child processes. Make sure those get blocked by blocking them in the parent process before thread creation.
|
Hi, thanks for finding the real root cause. It looks like it's a known issue of glib: It might be fixed in latest version of glib: But I've tested #96 on Fedora 41, that should have this fix, so I'll need to investigate a bit more. |
That change won't help, glib still installs a custom SIGCHLD handler and leaves it unblocked. |
|
Notable risk here is that trying to figure out where libraries might create threads is probably hopeless. Even if this works today, it's hard to be confident that threads won't be unexpectedly created someplace else in the future. Maybe it'd be better to block signals at the top of main, and then unblock where you're ready to handle them? Still, I would worry that a thread might be created anywhere. I think the fundamental problem here is you're using GChildWatch (otherwise, GLib would not install a SIGCHLD handler) but you also want to manually monitor for child processes exiting without GChildWatch. Why not just do it one way or the other instead of mixing both?
I think this merge request removes the only place GLib installs a SIGCHLD handler (although only if pidfd is supported by the kernel), so why wouldn't it help? |
Yes, that might be the a better option.
kmscon does not even use glib. It just uses pango for rendering, which uses glib with threads internally...
I only had a quick look, but AFAICT it uses pidfd but still installs a SIGCHLD handler unconditionally anyway. |
|
Font_pango is the only dependency that register a sigchild handler, so I think it's not a problem to put this workaround when loading font_pango. |
font_pango triggers creation of a glib thread which might capture SIGCHLD from child processes. Make sure those get blocked by blocking them in the parent process before thread creation.
Draft because this isn't really elegant and other signals might be affected as well?