Memory leak in audio pipeline
DC
daniel.comalrena at gmail.com
Wed Feb 22 17:10:52 UTC 2017
Hi,
I have important memory leaks when building and deallocating audio
transcoding pipelines in my application: more than 200kB per pipeline after
creating and destroying 50 pipelines (please find attached below the
pipeline diagram). In the long run, all RAM is used and even swap memory is
requested because of the application's appetite.
pipeline-diagram.png
<http://gstreamer-devel.966125.n4.nabble.com/file/n4681993/pipeline-diagram.png>
I deallocate each pipeline as expected:
/
if (gst_element_set_state(s->pipeline, GST_STATE_NULL) ==
GST_STATE_CHANGE_FAILURE)
{
LOG(LOG_INFO, "[eng%05u] Unable to set the pipeline to the NULL
state", s->id);
}
gst_object_unref (s->pipeline); /* should free all elements and bins
inside */
g_source_remove (s->bus_id);/
When running valgrind with mem-check for a single pipeline, I obtain as
"definitely lost":
/==00:00:01:22.953 31297== 7,754 (720 direct, 7,034 indirect) bytes in 1
blocks are definitely lost in loss record 3,266 of 3,281
==00:00:01:22.953 31297== at 0x586EA3A: g_type_create_instance (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.953 31297== by 0x585325C: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.953 31297== by 0x58551D3: g_object_new_valist (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.953 31297== by 0x58555D0: g_object_new (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.953 31297== by 0x556FBE4: gst_element_factory_create
(gstelementfactory.c:373)
==00:00:01:22.953 31297== by 0x556FEB0: gst_element_factory_make
(gstelementfactory.c:449)
==00:00:01:22.953 31297== by 0x41378F: add_encoder.isra.38
(tcgw_gstreamer.c:2494)
...
==00:00:01:22.953 31297==
==00:00:01:22.954 31297== 7,761 (720 direct, 7,041 indirect) bytes in 1
blocks are definitely lost in loss record 3,267 of 3,281
==00:00:01:22.954 31297== at 0x586EA3A: g_type_create_instance (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x585325C: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x58551D3: g_object_new_valist (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x58555D0: g_object_new (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x556FBE4: gst_element_factory_create
(gstelementfactory.c:373)
==00:00:01:22.954 31297== by 0x556FEB0: gst_element_factory_make
(gstelementfactory.c:449)
==00:00:01:22.954 31297== by 0x41378F: add_encoder.isra.38
(tcgw_gstreamer.c:2494)
...
==00:00:01:22.954 31297== 12,233 (712 direct, 11,521 indirect) bytes in 1
blocks are definitely lost in loss record 3,273 of 3,281
==00:00:01:22.954 31297== at 0x586EA3A: g_type_create_instance (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x585325C: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x58551D3: g_object_new_valist (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x58555D0: g_object_new (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x556FBE4: gst_element_factory_create
(gstelementfactory.c:373)
==00:00:01:22.954 31297== by 0x556FEB0: gst_element_factory_make
(gstelementfactory.c:449)
==00:00:01:22.954 31297== by 0x418220: add_decoder
(tcgw_gstreamer.c:1667)
...
==00:00:01:22.954 31297== 12,234 (720 direct, 11,514 indirect) bytes in 1
blocks are definitely lost in loss record 3,274 of 3,281
==00:00:01:22.954 31297== at 0x586EA3A: g_type_create_instance (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x585325C: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x58551D3: g_object_new_valist (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x58555D0: g_object_new (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
==00:00:01:22.954 31297== by 0x556FBE4: gst_element_factory_create
(gstelementfactory.c:373)
==00:00:01:22.954 31297== by 0x556FEB0: gst_element_factory_make
(gstelementfactory.c:449)
==00:00:01:22.954 31297== by 0x418220: add_decoder
(tcgw_gstreamer.c:1667)
...
==00:00:01:22.955 31297== LEAK SUMMARY:
==00:00:01:22.955 31297== definitely lost: 2,872 bytes in 4 blocks
==00:00:01:22.955 31297== indirectly lost: 37,110 bytes in 92 blocks
==00:00:01:22.955 31297== possibly lost: 322 bytes in 3 blocks
==00:00:01:22.955 31297== still reachable: 353,600 bytes in 1,116 blocks/
mem-check1.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/n4681993/mem-check1.txt>
Which looks linked to the decoder/encoder elements (though only ~40kB). I
tried to deference them directly before deferencing the pipeline (although
they should have been dereferenced when dereferencing the pipeline):
/ gst_object_unref(bin_src->decoder);
gst_object_unref(bin_sink->encoder);/
Mem-check now looks much better...
/==00:00:00:49.823 22590== LEAK SUMMARY:
==00:00:00:49.823 22590== definitely lost: 0 bytes in 0 blocks
==00:00:00:49.823 22590== indirectly lost: 0 bytes in 0 blocks
==00:00:00:49.823 22590== possibly lost: 322 bytes in 3 blocks
==00:00:00:49.823 22590== still reachable: 353,602 bytes in 1,116 blocks
==00:00:00:49.823 22590== suppressed: 248,844 bytes in 2,280 blocks/
mem-check2.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/n4681993/mem-check2.txt>
...but memory leaks are still huge (~180kb) when measured with top.
Running valgrind with massif, several minutes after the last dereferenced
pipeline, the detailed snapshot shows lots of allocations related to
elements in the pipelines, although pipelines have already been freed long
ago (see file attached), examples:
massif-1.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/n4681993/massif-1.txt>
/...
| | | | ->05.04% (229,384B) 0x584B25B: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | ->04.93% (224,200B) 0x584CE1B: g_object_newv (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | ->04.22% (191,976B) 0x584D5E2: g_object_new (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | ->02.38% (108,232B) 0x879F062: rtp_source_new
(rtpsource.c:595)
...
| | | | | | ->01.65% (75,072B) 0x87A61A2: gst_rtp_session_init
(gstrtpsession.c:808)
| | | | | | | ->01.65% (75,072B) 0x5866999: g_type_create_instance (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | | ->01.65% (75,072B) 0x584B25B: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | | ->01.65% (75,072B) 0x584D1D2: g_object_new_valist (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | | ->01.65% (75,072B) 0x584D5CF: g_object_new (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | | ->01.65% (75,072B) 0x5567BE3:
gst_element_factory_create (gstelementfactory.c:373)
| | | | | | | ->01.65% (75,072B) 0x5567EAF:
gst_element_factory_make (gstelementfactory.c:449)
...
| | | | | | ->00.19% (8,672B) 0x8788F0C: gst_rtp_jitter_buffer_init
(gstrtpjitterbuffer.c:984)
| | | | | | | ->00.19% (8,672B) 0x5866999: g_type_create_instance (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | | ->00.19% (8,672B) 0x584B25B: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | | ->00.19% (8,672B) 0x584D1D2: g_object_new_valist (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | | ->00.19% (8,672B) 0x584D5CF: g_object_new (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | | | | | ->00.19% (8,672B) 0x5567BE3:
gst_element_factory_create (gstelementfactory.c:373)
...
| ->00.72% (32,768B) 0x52BA1EC: gst_adapter_init (gstadapter.c:198)
| | ->00.72% (32,768B) 0x5866999: g_type_create_instance (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | ->00.72% (32,768B) 0x584B25B: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | ->00.72% (32,768B) 0x584CE1B: g_object_newv (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | ->00.18% (8,192B) 0x5077D88: gst_audio_decoder_init
(gstaudiodecoder.c:473)
| | | ->00.18% (8,192B) 0x5866956: g_type_create_instance (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | ->00.18% (8,192B) 0x584B25B: ??? (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | ->00.18% (8,192B) 0x584D1D2: g_object_new_valist (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | ->00.18% (8,192B) 0x584D5CF: g_object_new (in
/usr/lib64/libgobject-2.0.so.0.4200.2)
| | | ->00.18% (8,192B) 0x5567BE3: gst_element_factory_create
(gstelementfactory.c:373)
| | | ->00.18% (8,192B) 0x5567EAF: gst_element_factory_make
(gstelementfactory.c:449)
...
/
Even encoder/decoder-related, which have been explicitly dereferenced.
What is missing when deallocating the pipeline?
Thanks for your help.
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Memory-leak-in-audio-pipeline-tp4681993.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
More information about the gstreamer-devel
mailing list