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 784276 - level: Memory leak
level: Memory leak
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.12.1
Other All
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-28 06:26 UTC by Vinod Kesti
Modified: 2017-07-24 11:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vinod Kesti 2017-06-28 06:26:01 UTC
Memory leak in level element when messages is enabled.

gst-launch-1.0 audiotestsrc ! level interval=100000 message=false ! fakesink --gst-debug=3

I used Linux top command to check the Memory usage. Running pipeline for long time makes system unstable.

With below pipeline memory leak is not observer.
gst-launch-1.0 audiotestsrc ! level interval=100000 message=true  ! fakesink --gst-debug=3

I tried to run pipeline through valgrind no lead reported by the tool.
==16178== LEAK SUMMARY:
==16178==    definitely lost: 0 bytes in 0 blocks
==16178==    indirectly lost: 0 bytes in 0 blocks
==16178==      possibly lost: 4,636 bytes in 61 blocks
==16178==    still reachable: 299,866 bytes in 1,966 blocks
==16178==                       of which reachable via heuristic:
==16178==                         length64           : 280 bytes in 7 blocks
==16178==                         newarray           : 1,568 bytes in 18 blocks
==16178==         suppressed: 0 bytes in 0 blocks

I am using gstreamer-1.12.1 for testing.
Comment 1 Sebastian Dröge (slomo) 2017-06-29 14:53:38 UTC
The pipeline with message=true uses a lot of memory here, the one with message=false doesn't. Did you mix them up?

Reason for the high, always increasing memory usage with message=true is that a message is posted on the bus for every single audio sample (100 microseconds), and they are not taken from the bus faster than that.
Comment 2 Tim-Philipp Müller 2017-06-29 16:25:02 UTC
Maybe we should just make level warn if the interval is set too low? (Assuming we won't be able to come up with a min value that we could put into the paramspec)
Comment 3 Vinod Kesti 2017-07-04 06:29:37 UTC
@Sebastian Dröge Yes I interchanged the pipelines. Sorry
With message post memory leak is seen.

I have run test cases for long duration by increasing the interval to 3 secs. 
I will check the memory usage after 48 hours.
Comment 4 Vinod Kesti 2017-07-24 11:38:32 UTC
No memory leak is not seen with 200msec interval, after weeks of long run.
Not a bug, it was configuration issue.

Thank you.