[gstreamer-bugs] [Bug 355499] New: ensure_current_registry_forking() fails if zombie already killed by signal handler

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=355499
 GStreamer | gstreamer (core) | Ver: HEAD CVS

           Summary: ensure_current_registry_forking()  fails if zombie
                    already killed by signal handler
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: seanegan at gmail.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


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.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.