[Bug 779053] gstplayer: Meet seek hang when trying to seek http streaming clips

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779053

--- Comment #16 from Lyon <lyon.wang at nxp.com> ---
>From thread 2 (gstplayer)
it hangs at g_mutex_lock() in aiurdemux
#0  0x76c54dbc in syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x76d7b398 in g_mutex_lock_slowpath (mutex=mutex at entry=0x24a210) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/glib/gthread-posix.c:1312
#2  0x76d7bc68 in g_mutex_lock (mutex=mutex at entry=0x24a210) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/glib/gthread-posix.c:1336
#3  0x74a6291c in gst_aiurdemux_handle_src_event (event=0x73af0098,
pad=<optimized out>, demux=0x24a150 [GstAiurDemux]) at aiurdemux.c:3701
#4  0x74a6291c in gst_aiurdemux_handle_src_event (pad=<optimized out>,
parent=<optimized out>, event=0x73af0098) at aiurdemux.c:690
#5  0x76eb3b6c in gst_pad_send_event_unchecked (pad=pad at entry=0x73929ab8
[GstPad], event=event at entry=0x73af0098, type=<optimized out>,
type at entry=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)

aiurdemux is the demux plugin we used in the pipeline.
Here is the situation, in http streaming mode.
There is one thread aiur_push, a loop to process the data got and push to
downstream. and there is one mutex lock in this thread. when unlock the mutex
when quit the loop.
When seeking, in handle src seek event, it will set the push loop to false and
make it quit, meanwhile lock mutex to wait the streaming finished, and then do
flush and seek.
however, seems the aiur_push thread loop is never quit and the mutex is never
been released, so it locked in waiting for streaming finished.


I'm still trying to figure out why the aiur_push loop not quit.
when not using gstplayer, the loop is quit successfully and the unlock the
mutex, which will not meet the deadlock issue.


I'm still trying to figure out why the aiur_push loop not quit.
when not using gstplayer, the loop quit successfully and will unlock the mutex,
which will not meet the deadlock issue.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.