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 697215 - pad: discoverer timeout could flush the element pads while peer seetcaps
pad: discoverer timeout could flush the element pads while peer seetcaps
Status: RESOLVED DUPLICATE of bug 701763
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-03 20:02 UTC by Alban Browaeys
Modified: 2013-07-24 09:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix discoverer timeout mangling the state of an element when it is passing data between src and sink (3.38 KB, patch)
2013-04-03 20:02 UTC, Alban Browaeys
rejected Details | Review

Description Alban Browaeys 2013-04-03 20:02:46 UTC
Created attachment 240540 [details] [review]
fix discoverer timeout mangling the state of an element when it is passing data between src and sink

Gst discoverer timeout change the state of the pipeline thus if the
    discover thread has not complete its discovery processing.
    Here in the main thread, the timeout set the avdec_dvvideo sink pad
    to flushing when it  pre_activate to false - GST_MODE_NONE - in
     gst_pad_activate_mode.
    This when the discover thread has not yet added the buffer pool :
    gst_video_decoder_negotiate_default attempts to set the caps before
    calling the decide_allocation handler and as the pad is flushing this
    returns false, decide_allocation never happens (thus get_output_buffer
    from avvidedec fails).
    
    Fixed by enclosing gst_pad_push_data content with the pad stream locking.
    My understanding is that pad_push_data pass data from one element pad to
    the same element peer pad.
    Also pad stream lock is recursive while element lock is not. Same for
    pad gst object lock. So locking on them on the discoverer timeout
    is not an option as this handler calls functions which also lock on both
    of them.


backtrace: thread "6" is the discoverer thread , thread "1" the discoverer timeout one.

Thread 6 (Thread 0x7fc9a3225700 (LWP 21513))

  • #0 gst_pad_push_event
    at gstpad.c line 4676
  • #1 gst_pad_set_caps
    at /opt/gnome/include/gstreamer-1.0/gst/gstcompat.h line 54
  • #2 gst_video_decoder_negotiate_default
    at gstvideodecoder.c line 2967
  • #3 gst_video_decoder_negotiate
    at gstvideodecoder.c line 3054
  • #4 gst_video_decoder_allocate_output_frame
    at gstvideodecoder.c line 3140
  • #5 get_output_buffer
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/gst-libav/ext/libav/gstavviddec.c line 957
  • #6 gst_ffmpegviddec_video_frame
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/gst-libav/ext/libav/gstavviddec.c line 1145
  • #7 gst_ffmpegviddec_frame
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/gst-libav/ext/libav/gstavviddec.c line 1219
  • #8 gst_ffmpegviddec_handle_frame
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/gst-libav/ext/libav/gstavviddec.c line 1335
  • #9 gst_video_decoder_decode_frame
    at gstvideodecoder.c line 2697
  • #10 gst_video_decoder_chain_forward
    at gstvideodecoder.c line 1737
  • #11 gst_video_decoder_chain
    at gstvideodecoder.c line 1984
  • #12 gst_pad_chain_data_unchecked
    at gstpad.c line 3652
  • #13 gst_pad_push_data
    at gstpad.c line 3869
  • #14 gst_pad_push
    at gstpad.c line 3972
  • #15 gst_single_queue_push_one
    at gstmultiqueue.c line 1057
  • #16 gst_multi_queue_loop
    at gstmultiqueue.c line 1303
  • #17 gst_task_func
    at gsttask.c line 316
  • #18 default_func
    at gsttaskpool.c line 70
  • #19 g_thread_pool_thread_proxy
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/glib/glib/gthreadpool.c line 309
  • #20 g_thread_proxy
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/glib/glib/gthread.c line 798
  • #21 start_thread
    at pthread_create.c line 311
  • #22 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 113

Thread 1 (Thread 0x7fc9fe6fd700 (LWP 21451))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 135
  • #1 _L_lock_1027
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __GI___pthread_mutex_lock
    at pthread_mutex_lock.c line 85
  • #3 g_rec_mutex_lock
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/glib/glib/gthread-posix.c line 379
  • #4 post_activate
    at gstpad.c line 886
  • #5 gst_pad_activate_mode
    at gstpad.c line 1067
  • #6 gst_pad_set_active
    at gstpad.c line 949
  • #7 activate_pads
    at gstelement.c line 2679
  • #8 gst_iterator_fold
    at gstiterator.c line 614
  • #9 iterator_activate_fold_with_resync
    at gstelement.c line 2699
  • #10 gst_element_pads_activate
    at gstelement.c line 2743
  • #11 gst_element_change_state_func
    at gstelement.c line 2807
  • #12 gst_video_decoder_change_state
    at gstvideodecoder.c line 2026
  • #13 gst_element_change_state
    at gstelement.c line 2594
  • #14 gst_element_set_state_func
    at gstelement.c line 2550
  • #15 gst_element_set_state
    at gstelement.c line 2451
  • #16 gst_bin_element_set_state
    at gstbin.c line 2297
  • #17 gst_bin_change_state_func
    at gstbin.c line 2599
  • #18 gst_decode_bin_change_state
    at gstdecodebin2.c line 4325
  • #19 gst_element_change_state
    at gstelement.c line 2594
  • #20 gst_element_set_state_func
    at gstelement.c line 2550
  • #21 gst_element_set_state
    at gstelement.c line 2451
  • #22 gst_bin_element_set_state
    at gstbin.c line 2297
  • #23 gst_bin_change_state_func
    at gstbin.c line 2599
  • #24 gst_uri_decode_bin_change_state
    at gsturidecodebin.c line 2635
  • #25 gst_element_change_state
    at gstelement.c line 2594
  • #26 gst_element_set_state_func
    at gstelement.c line 2550
  • #27 gst_element_set_state
    at gstelement.c line 2451
  • #28 gst_bin_element_set_state
    at gstbin.c line 2297
  • #29 gst_bin_change_state_func
    at gstbin.c line 2599
  • #30 gst_pipeline_change_state
    at gstpipeline.c line 471
  • #31 gst_element_change_state
    at gstelement.c line 2594
  • #32 gst_element_set_state_func
    at gstelement.c line 2550
  • #33 gst_element_set_state
    at gstelement.c line 2451
  • #34 discoverer_cleanup
    at gstdiscoverer.c line 1525
  • #35 async_timeout_cb
    at gstdiscoverer.c line 1585
  • #36 g_timeout_dispatch
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/glib/glib/gmain.c line 4413
  • #37 g_main_dispatch
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/glib/glib/gmain.c line 3054
  • #38 g_main_context_dispatch
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/glib/glib/gmain.c line 3630
  • #39 g_main_context_iterate
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/glib/glib/gmain.c line 3701
  • #40 g_main_loop_run
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/glib/glib/gmain.c line 3895
  • #41 ffi_call_unix64
    at ../src/x86/unix64.S line 76
  • #42 ffi_call
    at ../src/x86/ffi64.c line 522
  • #43 g_callable_info_invoke
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/gobject-introspection/girepository/gicallableinfo.c line 680
  • #44 g_function_info_invoke
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/gobject-introspection/girepository/gifunctioninfo.c line 274
  • #45 _invoke_callable
    at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/pygobject-python2/gi/pygi-invoke.c line 64
  • #46 pygi_callable_info_invoke
    at remote 0x3b68e88>,), kwargs={}, cache=0x4093060, function_ptr=0x0, user_data=0x0) at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/pygobject-python2/gi/pygi-invoke.c line 662
  • #47 _wrap_g_callable_info_invoke
    at remote 0x3b68e88>,), kwargs={}) at /home/prahal/Projects/Devel/Gnome/jhbuild/gnome/pygobject-python2/gi/pygi-invoke.c line 685
  • #48 ext_do_call
    at ../Python/ceval.c line 4331
  • #49 PyEval_EvalFrameEx
    at remote 0x3b68e88>,), kwargs={}), throwflag=throwflag@entry=0) at ../Python/ceval.c line 2705
  • #50 PyEval_EvalCodeEx
  • #51 fast_function
    at ../Python/ceval.c line 4117
  • #52 call_function
    at ../Python/ceval.c line 4042
  • #53 PyEval_EvalFrameEx
    at ../Python/ceval.c line 2666
  • #54 fast_function
    at ../Python/ceval.c line 4107
  • #55 call_function
    at ../Python/ceval.c line 4042
  • #56 PyEval_EvalFrameEx
    at ../Python/ceval.c line 2666
  • #57 fast_function
    at ../Python/ceval.c line 4107
  • #58 call_function
    at ../Python/ceval.c line 4042
  • #59 PyEval_EvalFrameEx
    at ../Python/ceval.c line 2666
  • #60 fast_function
    at ../Python/ceval.c line 4107
  • #61 call_function
    at ../Python/ceval.c line 4042
  • #62 PyEval_EvalFrameEx
    at ../Python/ceval.c line 2666
  • #63 fast_function
    at ../Python/ceval.c line 4107
  • #64 call_function
    at ../Python/ceval.c line 4042
  • #65 PyEval_EvalFrameEx
  • #66 PyEval_EvalCodeEx
  • #67 PyEval_EvalCode
  • #68 run_mod.42740
  • #69 PyRun_FileExFlags
  • #70 PyRun_SimpleFileExFlags
    at ../Python/pythonrun.c line 943
  • #71 PyRun_AnyFileExFlags
    at ../Python/pythonrun.c line 747
  • #72 Py_Main
    at ../Modules/main.c line 640
  • #73 __libc_start_main
    at libc-start.c line 260
  • #74 _start

Comment 1 Sebastian Dröge (slomo) 2013-07-24 09:31:02 UTC
I think this is fixed nowadays. When flushing happens everything should stop as soon as possible, which means that gst_video_decoder_negotiate() will fail and that everything should go into flushing mode asap.
Comment 2 Sebastian Dröge (slomo) 2013-07-24 09:37:41 UTC
Comment on attachment 240540 [details] [review]
fix discoverer timeout mangling the state of an element when it is passing data between src and sink

<slomo> wtay: https://bugzilla.gnome.org/show_bug.cgi?id=697215  any idea about this one? it shouldn't happen anymore because of changes elsewhere, but why can it happen that the stream-lock is not taken there already (see the patch)?
<wtay> slomo, we don't take stream-lock on srcpads only on sinkpads
<wtay> slomo, and srcpads in pull mode
<slomo> i see
<wtay> also also on srcpads when using a task
<wtay> well, it does not have to be
<slomo> why not?
<wtay> there is no need to serialize pushes on the srcpad
<wtay> only on the sinkpads
<slomo> because when not using a task, it should already be protected by the sinkpad stream-lock?
<wtay> well, there is no need to serialize
<wtay> and yes, for shutdown of the element, we use the sinkpad lock
<wtay> when that's taken, we are sure nothing is inside the element pushing on the srcpad either
<slomo> ok, so that patch is not useful and only hiding another bug (that is fixed now)?
<slomo> do we also take the srcpad lock for shutdown? e.g. when the srcpad has its own task running?
<wtay> we do take the lock in shutdown but when in push mode, core does not take it
<wtay> so if the element is using a task, core will wait for the task to complete
Comment 3 Sebastian Dröge (slomo) 2013-07-24 09:39:06 UTC

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