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 111146 - new GstThread fails on pipeline with errors
new GstThread fails on pipeline with errors
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.9.4
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on: 112086
Blocks:
 
 
Reported: 2003-04-19 12:01 UTC by Wim Taymans
Modified: 2005-10-11 14:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Wim Taymans 2003-04-19 12:01:01 UTC
running gst-launch -v { fakesrc ! identity error_after=5 ! fakesink }

gives this error in GstThread:

/thread0/fakesink0: last-message = "chain   ******* (fakesink0:sink)< (0
bytes, 3, 0) 0x8061d10"
/thread0/fakesrc0: last-message = "get      ******* (fakesrc0:src)> (0
bytes, 4 ) 0x8061d10"
ERROR: /thread0/identity0: errored after iterations as requested
/thread0/identity0.sink: active = FALSE
/thread0/identity0.src: active = FALSE

GStreamer-ERROR **: file gstthread.c: line 356 (gst_thread_catch):
assertion failed: (!GST_FLAG_IS_SET (thread, GST_THREAD_STATE_SPINNING))
aborting...
Killed
Comment 1 Benjamin Otte (Company) 2003-04-21 18:30:19 UTC
Ok, Patch fixing this is in HEAD.
There are lots of races left however that can't be fixed by the thread
element. Best way to illustrate this is by using the above example.
Context switches to the other threads are done as I describe for the
purpose of reproducing the error. They might happen differently when
trying it.

gst-launch runs
...
THREAD 
Call to gst_element_error
state of thread element changes until gstelement.c:2465 when the
thread signals a state change and the main thread is woken up.
MAIN
Call to gst_element_set_state (thread, NULL)
set lots of variables (esp. element->current_state and
element->pending_state)
enter state change function of thread which blocks on
gst_thread_catch, because the mutex is still locked in gstthread.c:390
context switch
THREAD
continues at gstelement.c:2465
Goes on and finally exits thread's state_change handler. After this
the return value is compared to variables from element->current_state
and element->pending_state where it produces errors, because the
values changed (see above).
Goes on until it finishes the iteration and gets caught by the main
thread.
MAIN
Goes on in gstthread.c:390
Finds out that the element->current_state and element->pending_state
variables have been changed and warns. Goes on with the _old_ values
then, because it should work at least a little.

This is really not threadsafe, but works after the last patch.
Comment 2 Andy Wingo 2005-07-14 14:57:24 UTC
Does not crash in HEAD, but does lock up in the PLAYING->PAUSED transition.
Reopening, assigning to Wim to look at.
Comment 3 Andy Wingo 2005-10-11 14:13:02 UTC
Fixed in HEAD.