valgrind reports leaks for buffers allocated by niceesrc and Application

Pradeep Acharya pradeep.acharya1008 at gmail.com
Tue Sep 20 10:49:27 UTC 2022


Hi,
Any of you faced a similar leak in the pipeline as shown in below valgrind
report. The buffer given by appsink is unref by calling gst_sample_unref.
buffer leak is observed even after that.

Thanks

On Tue, Sep 13, 2022 at 2:30 PM Pradeep Acharya <
pradeep.acharya1008 at gmail.com> wrote:

> Hi ,
>
> I'm using webrtcbin plugin in my media server to make video calls using
> webRTC . Once data receive and transmit starts, memory usage consistently
> by 0.1 %  and this is shown in the top command.. when i executed my
> application using valgrind tool, the report shows "definitely leaks" for
> the buffers allocated by nice src plugin.
> 1.
> ==1105269== 4,345,040 bytes in 18,532 blocks ar*e definitely lost i*n
> loss record 8,466 of 8,480
> ==1105269==    at 0x4C30F0B: malloc (vg_replace_malloc.c:307)
> ==1105269==    by 0x56CAEA0: g_malloc (gmem.c:106)
> ==1105269==    by 0x56E2752: g_slice_alloc (gslice.c:1069)
> ==1105269==    by 0x59DE4EA: default_alloc (in
> /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)
> ==1105269==    by 0x59EB1C1: gst_buffer_new_allocate (in
> /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)
> ==1105269==    by 0x1897E9AA: gst_nice_src_read_callback (in
> /usr/local/lib64/gstreamer-1.0/libgstnice.so)
> ==1105269==    by 0x131C7675: nice_component_emit_io_callback (in
> /usr/local/lib64/libnice.so.10.11.0)
> ==1105269==    by 0x131C31BC: component_io_cb (in
> /usr/local/lib64/libnice.so.10.11.0)
> ==1105269==    by 0x6E13A68: socket_source_dispatch (gsocket.c:4007)
> ==1105269==    by 0x56C5320: g_main_dispatch (gmain.c:3325)
> ==1105269==    by 0x56C5320: g_main_context_dispatch (gmain.c:4043)
> ==1105269==    by 0x56C56B7: g_main_context_iterate.isra.23 (gmain.c:4119)
> ==1105269==    by 0x56C5969: g_main_loop_run (gmain.c:4317)
>
> buffers that are allocated by nicesrc should be consumed and freed by next
> element which is the queue element . Is that not happening ? Any ideas on
> this. there is no configuration  to restrict the number of buffers to be
> allocated. The plugin keeps allocating and memory usage increases. Any
> suggestions on this would be helpful
>
> 2. The second problem which is see is that the Gstbuffer allocated by
> application and given to appsrc plugin is not freed and shows up in the
> valgrind report. the buffer allocated by the application is given to the *appsrc
> *plugin. As per my knowledge, appsrc will unref the buffer once it's
> consumed. If so , why is it not freed ? Should the application need to free
> the buffer or the appsrc plugin takes care of freeing ? Any suggestions on
> this would be helpful
>
> ==1176192== 9,933 (7,973 direct, 1,960 indirect) bytes in 7 blocks are
> definitely lost in loss record 9,028 of 9,100
> ==1176192==    at 0x4C30F0B: malloc (vg_replace_malloc.c:307)
> ==1176192==    by 0x56CAEA0: g_malloc (gmem.c:106)
> ==1176192==    by 0x56E2752: g_slice_alloc (gslice.c:1069)
> ==1176192==    by 0x59DE788: _sysmem_copy (in
> /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)
> ==1176192==    by 0x59EA6E8: gst_buffer_copy_into (in
> /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)
> ==1176192==    by 0x59ED90F: gst_buffer_copy_deep (in
> /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)
>
> Thanks
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220920/853beb73/attachment.htm>


More information about the gstreamer-devel mailing list