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 740009 - dashdemux: gst_dash_demux_download_wait causes abort for dynamic MPD
dashdemux: gst_dash_demux_download_wait causes abort for dynamic MPD
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-11-12 13:24 UTC by A Ashley
Modified: 2014-12-11 12:19 UTC
See Also:
GNOME target: ---
GNOME version: ---

claim mutex in gst_dash_demux_download_wait (1.51 KB, patch)
2014-11-12 13:33 UTC, A Ashley
none Details | Review

Description A Ashley 2014-11-12 13:24:20 UTC
Testing with DASH stream [1] that has MPD@type="dynamic" causes GStreamer to abort. Using a stream that has MPD@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=''

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 __kernel_vsyscall
  • #1 __GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 56
  • #2 __GI_abort
    at abort.c line 89
  • #3 ??
    from /lib/i386-linux-gnu/
  • #4 g_cond_wait_until
    from /lib/i386-linux-gnu/
  • #5 gst_dash_demux_download_wait
    at gstdashdemux.c line 2540
  • #6 gst_dash_demux_wait_for_fragment_to_be_available
    at gstdashdemux.c line 1970
  • #7 gst_dash_demux_stream_get_next_fragment
    at gstdashdemux.c line 2517
  • #8 gst_dash_demux_stream_download_loop
    at gstdashdemux.c line 1570
  • #9 gst_task_func
    at gsttask.c line 317
  • #10 default_func
    at gsttaskpool.c line 68
  • #11 ??
    from /lib/i386-linux-gnu/
  • #12 ??
    from /lib/i386-linux-gnu/
  • #13 start_thread
    at pthread_create.c line 309
  • #14 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 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

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

Comment 1 A Ashley 2014-11-12 13:33:57 UTC
Created attachment 290513 [details] [review]
claim mutex in gst_dash_demux_download_wait

I had a quick attempt to fix the bug by simply adding a g_mutex_lock in to gst_dash_demux_download_wait. This stops the abort, but when trying the problematic test stream, it now blocks waiting to preroll. Not sure if the preroll problem is another bug, or if this patch does not solve the problem.
Comment 2 Thiago Sousa Santos 2014-12-02 02:02:22 UTC
Can you test again with latest git master? I think this problem was addressed at the base class.
Comment 3 A Ashley 2014-12-11 10:23:57 UTC
I agree, I'm not seeing the problem when using the refactored version of dashdemux.
Comment 4 Tim-Philipp Müller 2014-12-11 12:18:47 UTC
Thanks for re-testing. Let's declare this fixed then :)