GNOME Bugzilla – Bug 355499
ensure_current_registry_forking() fails if zombie already killed by signal handler
Last modified: 2006-10-03 15:12:05 UTC
gst_init calls ensure_current_registry_forking() which forks. It then calls waitpid() on the child and fails initialization if waitpid() fails. If an application has a handler for SIGCHLD to kill zombies, the signal handler and ensure_current_registry_forking are in a race to kill the zombie; if the app gets it first, initialization fails. This was the case in Gaim. Our (hacky) workaround is to delay our waitpid() one second to allow gstreamer to kill it. Gstreamer 0.10.10 allows you to programmatically turn off forking programtically, but it would be nice if the forking behavior were changed to avoid this entirely; it could take an application developer a long time debugging to realize the problem and turn off forking. A suggestion would be to ignore the return value of waitpid and get back the status in a pipe.
Created attachment 73933 [details] [review] use pipes to read a result from the child This patch uses a pipe pair to receive a single byte result from the child indicating success or failure. It still does waitpid to ensure the child is reaped, but now ignores the result.
Created attachment 73950 [details] [review] Don't leak fd in the parent Updated patch that closes the read end of the pipe when done so the parent doesn't leak an fd.
I haven't tested this, but the updated version looks ok to me. Assuming it works, go ahead.
ta, committed: * gst/gst.c: (ensure_current_registry_forking): Use a pipe pair to receive status results from the forked child, and ignore the result from waitpid. Fixes #355499