This looks like it might be related to this fix in git:

http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=a626dff72c6dea80bfab31cf1810db724bc45afb

which, however, should as far as I understand it only be a problem on linux if registry forking is disabled explicitly (e.g. via the environment variable or API), ie. not in the default setup.

Also: why does pidgin use gst_deinit()? That's really not recommended for applications, it's primarily meant for unit tests and the like.

I'll check the patch. Yes, pidgin explicitly disables forking:

/* By default, gstreamer forks when you initialize it, and waitpids for the     
 * child.  But if libpurple reaps the child rather than leaving it to           
 * gstreamer, gstreamer's initialization fails.  So, we wait a second before    
 * reaping child processes, to give gst a chance to reap it if it wants to.     
 *                                                                              
 * This is not needed in later gstreamers, which let us disable the forking.    
 * And, it breaks the world on some Real Unices.                                
 */

> /* By default, gstreamer forks when you initialize it, and waitpids for the     
>  * child.  But if libpurple reaps the child rather than leaving it to           
>  * gstreamer, gstreamer's initialization fails.  So, we wait a second before    
>  * reaping child processes, to give gst a chance to reap it if it wants to.     
>  *                                                                              
>  * This is not needed in later gstreamers, which let us disable the forking.    
>  * And, it breaks the world on some Real Unices.                                
>  */

I'd be curious about how it breaks on Real Unices? (And which ones?)

The one-second timeout seems rather arbitrary, you can't realy rely on that, since it might depend on all kinds of things (disk access/spin-up etc.).

Also, I'm not sure how future-proof this all is. I think there are plans to move the actual plugin scanning into an external helper program at some point, which would probably be called via g_spawn_*(). Not sure if the plan includes a way to disable that.

Good questions. You should ask them to the Pidgin devs in the mentioned ticket.

> Good questions. You should ask them to the Pidgin devs in the mentioned ticket.

I don't think I can be bothered to register there just for this. Luckily this bug is referenced in the ticket, so hopefully some of the devs will find their way here.
 

The patch helped according to the original reporter.

I believe the referent of "it" in "it breaks the world on some Real Unices" is the signal hack needed for versions of GStreamer that do not allow pidgin to disable forking. Or at least that is what my reading of http://developer.pidgin.im/ticket/1496 is.

It appears that we (the pidgin developers) might be able to move this child reaping to another part of pidgin which may or may not be beneficial to the original problem here (and to any new problems that may come up if GStreamer moves to g_spawn:ing a helper program). I don't know enough to say.

And yes, the one second time out was entirely arbitrary but it appears to have worked well enough so far (for those few people using GStreamer versions older than 0.10.10).