[Bug 740009] New: dashdemux: gst_dash_demux_download_wait causes abort for dynamic MPD

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=740009
  GStreamer | gst-plugins-bad | git

           Summary: dashdemux: gst_dash_demux_download_wait causes abort
                    for dynamic MPD
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bugzilla at ashley-family.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Testing with DASH stream [1] that has MPD at type="dynamic" causes GStreamer to
abort. Using a stream that has MPD at type set to "static" [2] does not exhibit
this problem. Both streams use the same media fragments, the only difference is
the contents of the MPD.

Command line:
[GST] gst-plugins-bad> gst-launch-1.0 --gst-debug=dashdemux:5,3 playbin
uri='http://dash-live-streams.appspot.com/dash/manifest_e.mpd'

The console output prior to the abort:
0:00:00.398173450 17369  0x9b79bb0 DEBUG              dashdemux
gstmpdparser.c:3544:gst_mpd_client_get_next_fragment_timestamp: Looking for
fragment sequence chunk 4
0:00:00.398210606 17369  0x9b79bb0 DEBUG              dashdemux
gstdashdemux.c:1969:gst_dash_demux_wait_for_fragment_to_be_available:<dashdemux0>
Selected fragment has end timestamp > now (4718913000), delaying download
0:00:00.398236044 17369  0x9b79bb0 DEBUG              dashdemux
gstdashdemux.c:2539:gst_dash_demux_download_wait:<dashdemux0:ghostpad0>
Download waiting for 0:00:04.718913000
Attempt to unlock mutex that was not locked
Abort (core dumped)


Looking at the stack trace in the core file:
(gdb) bt
#0  0x40022c7c in __kernel_vsyscall ()
#1  0x40346577 in __GI_raise (sig=sig at entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0x40347cf3 in __GI_abort () at abort.c:89
#3  0x4025f7b0 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4  0x4026059f in g_cond_wait_until ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
#5  0x41975b3d in gst_dash_demux_download_wait (stream=0x4201a900, 
    time_diff=4784050000) at gstdashdemux.c:2540
#6  0x419781f7 in gst_dash_demux_wait_for_fragment_to_be_available (
    stream=<optimised out>, demux=<optimised out>) at gstdashdemux.c:1970
#7  gst_dash_demux_stream_get_next_fragment (ts=<optimised out>, 
    stream=<optimised out>) at gstdashdemux.c:2517
#8  gst_dash_demux_stream_download_loop (stream=0x4201a900)
    at gstdashdemux.c:1570
#9  0x400b4d84 in gst_task_func (task=0x420118e0) at gsttask.c:317
#10 0x400b5d97 in default_func (tdata=0x42013998, pool=0x9f97470)
    at gsttaskpool.c:68
#11 0x40241b34 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#12 0x402410ba in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#13 0x40300f16 in start_thread (arg=0x42903b40) at pthread_create.c:309
#14 0x404039fe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129

It appears that gst_dash_demux_download_wait issues a call to g_cond_wait_until
with a mutex that it does not hold. Searching the dashdemux code, I can't see
anywhere where that mutex is locked.

These tests were done with the current head of master from git:
[GST] gst-plugins-bad> git describe
1.4.0-643-g5e8624e

[GST] gst-plugins-bad> git log
commit 92796446a23bae05cf3fd70cfe161f04e0dac980
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Nov 12 09:41:53 2014 +0000

    [1] http://dash-live-streams.appspot.com/dash/manifest_e.mpd
    [2] http://dash-live-streams.appspot.com/dash/manifest_b.mpd

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.