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 744253 - multiqueue: Memory leak with DASH stream
multiqueue: Memory leak with DASH stream
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal blocker
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-10 11:39 UTC by Carlos Rafael Giani
Modified: 2015-03-15 14:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Carlos Rafael Giani 2015-02-10 11:39:23 UTC
Hello,

This gst-launch line leaks rapidly:

gst-launch-1.0 uridecodebin uri=http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-720p-stereo-nodvb.mpd caps="video/x-h264 ; audio/mpeg" ! fakesink sync=true

After examination, it turns out that the cause is an internal multiqueue that is steadily increasing its internal limit, apparently because one queue is not linked.

Here is an excerpt of log lines that show the leak:

gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2507/2508, bytes 6664375/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2508/2508, bytes 6667271/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2508/2509, bytes 6667271/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2509/2509, bytes 6670167/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2509/2510, bytes 6670167/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2510/2510, bytes 6673063/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2510/2511, bytes 6673063/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2511/2511, bytes 6675959/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2511/2512, bytes 6675959/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2512/2512, bytes 6677407/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2512/2513, bytes 6677407/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2513/2513, bytes 6681503/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2513/2514, bytes 6681503/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2514/2514, bytes 6681751/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2514/2515, bytes 6681751/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2515/2515, bytes 6684647/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2515/2516, bytes 6684647/0, time 7680000000/0
gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2516/2516, bytes 6687543/0, time 7680000000/0

and this shows when it is increased:

gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked
gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked
gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2448
gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked
gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked
gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2449
gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked
gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked
gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2450
gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked
gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked
gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2451
gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked
gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked
gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2452

This happens with all versions up to and including the current git one. On the PC it does not happen with playbin, however. It also does not happen wih these other pipelines:

gst-launch-1.0 uridecodebin uri=http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-720p-stereo-nodvb.mpd caps="audio/x-m4a ; video/quicktime" ! fakesink sync=true
gst-launch-1.0 souphttpsrc location=http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-720p-stereo-nodvb.mpd ! decodebin caps="video/x-h264 ; audio/mpeg" ! fakesink sync=true

I presume because in both cases, that multiqueue0 isn't present.
Comment 1 Sebastian Dröge (slomo) 2015-02-10 20:08:47 UTC
This was introduced as part of bug #719893 and bug #722891. Unfortunately nobody remembers why that was a good idea, and it also does not seem to make any sense at all currently.

Per, do you remember anything?
Comment 2 Per Johansson 2015-02-11 06:57:07 UTC
I don't remember the details either, but I was working with trying to solve issues with gaps in streams. We ended up using the watchdog element to handle the extreme cases, but I don't remember if we need these changes too to handle other cases.
Comment 3 Per Johansson 2015-02-11 07:15:58 UTC
If I remember correctly it will not grow indefinitely, just until one of the limits “max-size-bytes” or “max-size-time” is reached.
Comment 4 Sebastian Dröge (slomo) 2015-02-12 09:28:33 UTC
Problem is that both other limits are not set in this situation :)

Not sure how gaps would influence anything here. Do you mean gaps in the unlinked streams, or the one linked stream?
Comment 5 Sebastian Dröge (slomo) 2015-03-15 14:23:24 UTC
commit 5fc2a3fd6683541aae2ac9a6053d2f71b232db69
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Sun Mar 15 14:19:17 2015 +0000

    multiqueue: Don't grow queue infinitely if only one pad is linked
    
    This was introduced by
    https://bugzilla.gnome.org/show_bug.cgi?id=719893
    https://bugzilla.gnome.org/show_bug.cgi?id=722891
    but it doesn't make any sense at all and causes huge memory leaks.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=744253