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 608533 - [real] memory leak in real audio stream via rtsp
[real] memory leak in real audio stream via rtsp
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.13
Other Linux
: Normal major
: 0.10.14
Assigned To: Tim-Philipp Müller
GStreamer Maintainers
Depends on:
Blocks: 608564
 
 
Reported: 2010-01-30 15:43 UTC by Massimiliano
Modified: 2010-01-30 23:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Valgrind log of gst-launch uridecodebin uri=rtsp://live.media.rai.it/broadcast/radiodue.rm ! fakesink (65.68 KB, text/plain)
2010-01-30 15:43 UTC, Massimiliano
Details

Description Massimiliano 2010-01-30 15:43:55 UTC
Created attachment 152637 [details]
Valgrind log of gst-launch uridecodebin uri=rtsp://live.media.rai.it/broadcast/radiodue.rm ! fakesink

I noticed a constant growth in memory footprint while running a chain decoding a .rm stream. Narrowed down the problem to the decoding part of the chain. 

The command I'm using for the test is 

gst-launch uridecodebin uri=rtsp://live.media.rai.it/broadcast/radiodue.rm ! fakesink

The memory footprint of the command grows at the rate of ~1M every 5 mins.

It seems the leak is somewhere in the real decoding of the rtsp stream. See the attached valgrind log of a ~5 mins run of the chain. Valgrinds mark about 1.5M of definetely lost bytes. Command used to produce the log was:

G_SLICE=always-malloc G_DEBUG=gc-friendly GLIBCPP_FORCE_NEW=1 GLIBCXX_FORCE_NEW=1 valgrind --log-file=testchain.txt --tool=memcheck --leak-check=full --leak-resolution=low    --trace-children=yes --num-callers=20 -v gst-launch uridecodebin uri=rtsp://live.media.rai.it/broadcast/radiodue.rm ! fakesink

I was unable to reproduce in valgrind using just rtspsrc location=rtsp://live.media.rai.it/broadcast/radiodue.rm ! fakesink.
Comment 1 Massimiliano 2010-01-30 23:05:39 UTC
Not really a proposed patch, anyway... It seems that adding 
  g_buffer_unref(buffer);
in line 854 of rdtmanager.c, after
  result = gst_pad_push (session->recv_rtp_src, buffer);
solves the leak. Anyway I can't understand what's going on, since gst_pad_push is supposed to take over the reference of the buffer...
Comment 2 Tim-Philipp Müller 2010-01-30 23:19:26 UTC
This fixes most of it for me:

commit cd6b16734eeeaa7d73b6a62febac068459cf6882
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Sat Jan 30 19:12:24 2010 +0000

    rtspreal: add finalize function so we can free streams and rulebook
    
    Fix memory leak in Real RTSP component (#608533).

commit 4cb5f323080a493d6a102afe9cb7700eee3410a3
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Sat Jan 30 19:10:45 2010 +0000

    rtspreal: fix minor memory leak
    
    Caps take their own reference when a buffer is added to them, so
    unref buffer after adding it to caps (#608533).

commit 29c509a7b82579eb055a37f55e2110e20dd7e3b9
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Sat Jan 30 19:06:34 2010 +0000

    rdtdepay: unref input buffer when done
    
    Fixes memory leak, see #608533.


There's still a buffer leak in gst-ffmpeg though, for which I'll file a separate bug.