Killing Zombies - Unref-ing pipelines waiting for async change

Wes Miller wmiller at
Thu Aug 11 05:45:33 PDT 2011

Michael, the code is in the note itself.  I didn't paste in all the unrelated
pipe building stuff and my first note said "I have a program with a receiver
pipeline (essentially, udpsrc->decodebin->autoaudiosinkl".  

This has turned into an interesting problem.  Michael and Nicola were
correct.  The use of:

created problems and isn't needed.

The part I left out of my explanation, apologies to all, the pipeline was
running in a separate thread from the class destructor that was trying to
kill off the "stuck", async, pipeline.   It was coded more or less as in all
the examples:

Here is what was happening: 
The destructor, in its separate thread, set the recvPipeline state to NULL
and unrefed the pipeline and loop.  
In the pipeline's thread, the gst_element_get_state() was no longer ASYNC so
the gst_element_get_state() returned and the code above resumed trying to
run the (unref-ed)pipeline and enter the (unref-ed)main loop.  This spit out
all sorts of CRITICAL messages and warnings about invalid objects and
refcounts > 0.

The fix was to, 
1. remove the unrefs from the destructor, letting the other thread handle
those operations.  Then  
2.fix the pipeline code thus:

Hope this helps the next guy and many thanks to Nicola and Michael.


View this message in context:
Sent from the GStreamer-devel mailing list archive at

More information about the gstreamer-devel mailing list