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 90885 - set_state(READY) wont work on my machine
set_state(READY) wont work on my machine
Status: VERIFIED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.4.0
Other Linux
: Normal normal
: 0.4.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-08-15 21:48 UTC by florianbe
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description florianbe 2002-08-15 21:48:54 UTC
i have run my program on 3 machines:
an IPAQ (familiar-0.5.3), an Atlon1000 (Mandrake 8.1) and an Athlon 
XP+1700 with SuSE 7.2.
it runs correctly on the first two, however, on the last one it wont work.
(it hangs in gst_element_set_state when setting READY state the second 
time - the first time setting READY makes no problems)

im using the gst_play-class of steveb and all my code does until hanging 
is:
    gst_init (&argc, &argv);
    play = gst_play_new (GST_PLAY_PIPE_VIDEO);
    gst_play_set_state (play, GST_STATE_READY);
    gst_play_set_state (play, GST_STATE_READY); <-- here it hangs


here the tail of the gst-mask=-1 output:

DEBUG( 1859: 0)cothread_stackquery:552: Got new cothread stack from 
0x40c00000 to 0x40dfffff (size 2097152)
DEBUG( 1859: 0)gst_basic_scheduler_get_preferred_stack:958: getting 
preferred stack size as 0x40c00000 and 2097152

(process:1859): GStreamer-WARNING **: pthread_attr_setstack failed
DEBUG( 1859: 0)gst_element_set_state:1867: [work_thread] have failed 
change_state return
DEBUG( 1859: 0)gst_bin_change_state:540: child 'work_thread' failed to go 
to state 2(READY)
DEBUG( 1859: 0)gst_element_set_state:1829: [work_thread] setting state 
from NULL to NULL
INFO ( 1859: 0)gst_bin_change_state:567: [main_pipeline] done changing 
bin's state from NULL to READY, now in NULL
DEBUG( 1859: 0)gst_element_set_state:1880: [main_pipeline] element 
claimed state-change success, but state didn't change NULL, NONE_PENDING 
<-> READY
DEBUG( 1859: 0)gst_element_set_state:1829: [main_pipeline] setting state 
from NULL to READY
INFO ( 1859: 0)gst_bin_change_state:521: [main_pipeline] changing 
childrens' state from NULL to READY
DEBUG( 1859: 0)gst_element_set_state:1829: [work_thread] setting state 
from NULL to READY
INFO ( 1859: 0)gst_thread_change_state:258: [work_thread] sync(0): 
changing state from NULL to READYDEBUG( 1859: 
0)gst_thread_change_state:272: [work_thread] sync(0): creating thread 
"work_thread"
Comment 1 Thomas Vander Stichele 2002-08-17 17:59:10 UTC
out of curiosity, why do you set it to PLAYING twice in a row ?
My hunch is that we have a race condition there; you're trying to set
it to PLAYING, and the core signals the thread to go to PLAY, but it's
not done by the time the second _set starts.

It's something that should be fixed in any case, but please try with
only one set to PLAY and let us know how that changes things.
Comment 2 Christian Fredrik Kalager Schaller 2002-11-15 20:12:57 UTC
nothing heard. closing.