Memory leak in capsfilter application/x-rtp
David Ing
ding at panopto.com
Tue Nov 26 17:14:09 UTC 2019
I am no expert ... so maybe someone else will provide you with better
guidance. But I am guessing that the bug is in this code:
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi
You can file a new issue in gitlab (giving full repro steps), and your
issue will probably be triaged by the best expert in that area. You may
receive better guidance at that time.
On Tue, Nov 26, 2019 at 2:54 AM Saurabh Bora <saurabh9bora at gmail.com> wrote:
> Thank You David for the response.
>
> Please note that I am using GStreamer version 1.14.5
>
> I ran valgrind with environment variables as you suggested.
> Please find the attached report (streaming_app_valgrind.log)
>
> From the valgrind report, I could see memory lost at following places:
> ==12284== by 0x9C73966: gst_rtp_base_payload_sink_event_default (in
> /home/xruser/lib/libgstrtp-1.0.so.0.1405.0)
>
> ==12284== by 0xBC08E07: gst_vaapipostproc_start (in
> /home/xruser/lib/gstreamer-1.0/libgstvaapi.so)
>
> ==12284== by 0xBBFF6F5: plugin_init (in
> /home/xruser/lib/gstreamer-1.0/libgstvaapi.so)
>
> ==12284== by 0xBC03A36: gst_vaapi_plugin_base_ensure_display (in
> /home/xruser/lib/gstreamer-1.0/libgstvaapi.so)
>
> ==12284== by 0xBC08E07: gst_vaapipostproc_start (in
> /home/xruser/lib/gstreamer-1.0/libgstvaapi.so)
>
>
> Experts, please take a look at the valgrind report and guide me further.
>
> Thanks and Regards,
> Saurabh Bora
>
>
>
> On Tue, Nov 26, 2019 at 1:00 AM David Ing <ding at panopto.com> wrote:
>
>> If you are running on Linux you can try using valgrind.
>>
>> First you need to use these variables at runtime so that memory
>> allocation is performed in a "normal" way (such that valgrind can detect
>> problems).
>>
>>
>> G_DEBUG="gc-friendly"
>> G_SLICE="always-malloc"
>>
>>
>> The following command can be used to run valgrind where $@ represents
>> the arguments that are passed to the executable.
>>
>> valgrind \
>> --trace-children=yes \
>> --tool=memcheck \
>> --leak-check=full \
>> --leak-resolution=high \
>> --errors-for-leak-kinds=definite,indirect \
>> --show-leak-kinds=definite,indirect \
>> --show-possibly-lost=no \
>> --num-callers=20 \
>> --error-exitcode=20 \
>> --gen-suppressions=all \
>> executable_name $@
>>
>>
>> On Mon, Nov 25, 2019 at 11:10 AM Saurabh Bora <saurabh9bora at gmail.com>
>> wrote:
>>
>>> Hi Experts,
>>>
>>> I have a gstreamer test pipeline which I run as below:
>>> gst-launch-1.0 videotestsrc is-live=yes ! aspectratiocrop
>>> aspect-ratio=4/3
>>> ! vp8enc ! rtpvp8pay !
>>> application/x-rtp,media=video,encoding-name=VP8,payload=96 ! rtpvp8depay
>>> !
>>> decodebin ! autovideosink
>>>
>>> Also, I have following environment variables set to generate leak trace:
>>> set GST_DEBUG=GST_TRACER:7
>>> set GST_TRACERS=leaks
>>> set GST_DEBUG_FILE=logTrace
>>>
>>> Below is content of logTrace file, which shows leak in capsfilter -
>>> application/x-rtp,media=video,encoding-name=VP8,payload=96. As all the
>>> elements in the pipeline are gstreamer provided and not custom, I do not
>>> understand how I can fix this. Please help and guide.
>>>
>>>
>>> ========================================================================================================================
>>> 0:00:00.802370800 36936 0000000003F425A0 DEBUG GST_TRACER
>>> gsttracer.c:164:gst_tracer_register:<registry0> update existing feature
>>> 0000000001077180 (latency)
>>> 0:00:00.802895700 36936 0000000003F425A0 DEBUG GST_TRACER
>>> gsttracer.c:164:gst_tracer_register:<registry0> update existing feature
>>> 0000000001077240 (log)
>>> 0:00:00.802943700 36936 0000000003F425A0 DEBUG GST_TRACER
>>> gsttracer.c:164:gst_tracer_register:<registry0> update existing feature
>>> 0000000001077300 (stats)
>>> 0:00:00.802988600 36936 0000000003F425A0 DEBUG GST_TRACER
>>> gsttracer.c:164:gst_tracer_register:<registry0> update existing feature
>>> 00000000010773C0 (leaks)
>>> 0:00:00.803093500 36936 0000000003F425A0 TRACE GST_TRACER
>>> gsttracerrecord.c:111:gst_tracer_record_build_format: object-alive.class,
>>> type-name=(structure)"value\,\ type\=\(type\)gchararray\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> address=(structure)"value\,\ type\=\(type\)gpointer\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> description=(structure)"value\,\ type\=\(type\)gchararray\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> ref-count=(structure)"value\,\ type\=\(type\)guint\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> trace=(structure)"value\,\ type\=\(type\)gchararray\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;";
>>> 0:00:00.803149100 36936 0000000003F425A0 DEBUG GST_TRACER
>>> gsttracerrecord.c:125:gst_tracer_record_build_format: new format string:
>>> object-alive, type-name=(string)%s, address=(gpointer)%p,
>>> description=(string)%s, ref-count=(uint)%u, trace=(string)%s;
>>> 0:00:00.803360100 36936 0000000003F425A0 TRACE GST_TRACER
>>> gsttracerrecord.c:111:gst_tracer_record_build_format: object-refings.class,
>>> ts=(structure)"value\,\ type\=\(type\)guint64\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> type-name=(structure)"value\,\ type\=\(type\)gchararray\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> address=(structure)"value\,\ type\=\(type\)gpointer\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> description=(structure)"value\,\ type\=\(type\)gchararray\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> ref-count=(structure)"value\,\ type\=\(type\)guint\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;",
>>> trace=(structure)"value\,\ type\=\(type\)gchararray\,\
>>> related-to\=\(GstTracerValueScope\)GST_TRACER_VALUE_SCOPE_PROCESS\;";
>>> 0:00:00.803498500 36936 0000000003F425A0 DEBUG GST_TRACER
>>> gsttracerrecord.c:125:gst_tracer_record_build_format: new format string:
>>> object-refings, ts=(guint64)%I64u, type-name=(string)%s,
>>> address=(gpointer)%p, description=(string)%s, ref-count=(uint)%u,
>>> trace=(string)%s;
>>> 0:00:03.355505900 36936 0000000003F425A0 TRACE GST_TRACER
>>> :0:: object-alive, type-name=(string)GstCaps,
>>> address=(gpointer)0000000004A7F890, description=(string)application/x-rtp,
>>> payload=(int)96, clock-rate=(int)90000, encoding-name=(string)VP8,
>>> media=(string)video, ref-count=(uint)1, trace=(string);
>>>
>>> ==========================================================================================================================
>>>
>>> P.S.- The above pipeline is a test pipeline used to demonstrate leak. My
>>> original pipeline uses the same capsfilter and hence I need to fix this
>>> leak.
>>>
>>> Help Appreciated !
>>>
>>> --------
>>> Thanks and Regards,
>>> Saurabh Bora
>>>
>>> PH NO : 7038166900
>>> EMAIL : saurabh9bora at gmail.com
>>> saurabh9bora at outlook.com
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> --
> Thanks and Regards,
> Saurabh Bora
>
> PH NO : 7038166900
> EMAIL : saurabh9bora at gmail.com
> saurabh9bora at outlook.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191126/5956c04d/attachment.html>
More information about the gstreamer-devel
mailing list