Bug 329890 – gst_element_set_state blocks

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 329890 - gst_element_set_state blocks


Summary:	gst_element_set_state blocks


Status:	RESOLVED DUPLICATE of bug 320340

Product:	GStreamer
Classification:	Platform
Component:	gstreamer (core)
Version:	0.10.2
Hardware:	Other All

Importance:	Normal blocker
Target Milestone:	git master
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2006-02-04 14:15 UTC by Christian Prochnow
Modified:	2006-02-14 09:07 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Christian Prochnow 2006-02-04 14:15:41 UTC

Please describe the problem:
When calling gst_element_set_state(GST_STATE_NULL) from an event probe callback  
the function blocks the application, if the bin contains a queue element.  

Steps to reproduce:
1. create a bin with a ghost src pad which contains a filesrc and decodebin  
2. add the bin together with an adder element and a audiosink to the pipeline  
3. install an event probe callback on the requested sink pad of the adder  
4. in the event probe callback call gst_element_set_state(GST_STATE_NULL) on  
the bin 

Actual results:
the application blocks in gst_element_set_state. timers are run  

Expected results:
gst_element_set_state does not block 

Does this happen every time?
yes 

Other information:
Backtrace:

+ Trace 65909

#0 pthread_cond_wait
from /lib/tls/libpthread.so.0
#1 gst_task_join
from /usr/lib/libgstreamer-0.10.so.0
#2 gst_pad_stop_task
from /usr/lib/libgstreamer-0.10.so.0
#3 gst_queue_get_type
from /usr/lib64/gstreamer-0.10/libgstcoreelements.so
#4 gst_pad_activate_push
from /usr/lib/libgstreamer-0.10.so.0
#5 gst_pad_set_active
from /usr/lib/libgstreamer-0.10.so.0
#6 gst_element_lost_state
from /usr/lib/libgstreamer-0.10.so.0
#7 gst_iterator_fold
from /usr/lib/libgstreamer-0.10.so.0
#8 gst_element_lost_state
from /usr/lib/libgstreamer-0.10.so.0
#9 gst_element_lost_state
from /usr/lib/libgstreamer-0.10.so.0
#10 gst_element_lost_state
from /usr/lib/libgstreamer-0.10.so.0
#11 gst_element_continue_state
from /usr/lib/libgstreamer-0.10.so.0
#12 gst_element_lost_state
from /usr/lib/libgstreamer-0.10.so.0
#13 gst_element_set_state
from /usr/lib/libgstreamer-0.10.so.0
#14 gst_bin_iterate_sorted
from /usr/lib/libgstreamer-0.10.so.0
#15 ??
from /usr/lib64/gstreamer-0.10/libgstdecodebin.so
#16 gst_element_continue_state
from /usr/lib/libgstreamer-0.10.so.0
#17 gst_element_lost_state
from /usr/lib/libgstreamer-0.10.so.0
#18 gst_element_set_state
from /usr/lib/libgstreamer-0.10.so.0
#19 gst_bin_iterate_sorted
from /usr/lib/libgstreamer-0.10.so.0
#20 gst_element_continue_state
from /usr/lib/libgstreamer-0.10.so.0
#21 gst_element_lost_state
from /usr/lib/libgstreamer-0.10.so.0
#22 gst_element_set_state
from /usr/lib/libgstreamer-0.10.so.0
#23 gst::Element::setState(GstState)
at gst_element.h line 43
#24 StreamPlayer::onEOS(StreamInputBin*)
at /home/voltage/src/c_treamer/src/streammanager.cpp line 140
#25 StreamPipeline::EventProbeCallback::callback(_GstPad*, _GstMiniObject*)
at /home/voltage/src/c_treamer/src/streampipeline.cpp line 47
#26 gst::EventProbeCallback::_callback(_GstPad*, _GstMiniObject*, gst::EventProbeCallback*)
at /home/voltage/src/c_treamer/src/gst_pad.cpp line 71
#27 gst_marshal_BOOLEAN__POINTER
from /usr/lib/libgstreamer-0.10.so.0
#28 g_closure_invoke
from /usr/lib/libgobject-2.0.so.0
#29 g_signal_has_handler_pending
from /usr/lib/libgobject-2.0.so.0
#30 g_signal_emitv
from /usr/lib/libgobject-2.0.so.0
#31 gst_pad_load_and_link
from /usr/lib/libgstreamer-0.10.so.0
#32 gst_pad_send_event
from /usr/lib/libgstreamer-0.10.so.0
#33 gst_proxy_pad_get_type
from /usr/lib/libgstreamer-0.10.so.0
#34 gst_pad_send_event
from /usr/lib/libgstreamer-0.10.so.0
#35 gst_pad_push_event
from /usr/lib/libgstreamer-0.10.so.0
#36 gst_pad_event_default
from /usr/lib/libgstreamer-0.10.so.0
#37 gst_base_transform_set_passthrough
from /usr/lib/libgstbase-0.10.so.0
#38 gst_pad_send_event
from /usr/lib/libgstreamer-0.10.so.0
#39 gst_proxy_pad_get_type
from /usr/lib/libgstreamer-0.10.so.0
#40 gst_pad_send_event
from /usr/lib/libgstreamer-0.10.so.0
#41 gst_pad_push_event
from /usr/lib/libgstreamer-0.10.so.0
#42 gst_vorbis_dec_get_type
from /usr/lib64/gstreamer-0.10/libgstvorbis.so
#43 gst_pad_send_event
from /usr/lib/libgstreamer-0.10.so.0
#44 gst_pad_push_event
from /usr/lib/libgstreamer-0.10.so.0
#45 gst_queue_get_type
from /usr/lib64/gstreamer-0.10/libgstcoreelements.so
#46 gst_task_get_type
from /usr/lib/libgstreamer-0.10.so.0
#47 g_thread_pool_free
from /usr/lib/libglib-2.0.so.0
#48 g_static_private_free
from /usr/lib/libglib-2.0.so.0
#49 start_thread
from /lib/tls/libpthread.so.0
#50 clone
from /lib/tls/libc.so.6

Comment 1 Jan Schmidt 2006-02-04 18:04:37 UTC

I don't think there's much we can do to avoid this - the queue can't shut down if the state change is being called from the streaming thread. 

Pad probe callbacks happen from the streaming thread, so that's always going to be true.

It's not a queue specific problem, it will happen with any element that runs its own pad task, it just happens that queue is the most common one that does that.

Comment 2 Wim Taymans 2006-02-14 09:07:40 UTC


*** This bug has been marked as a duplicate of 320340 ***