<div dir="ltr"><div>Hi, <br></div><div>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. <br></div><div><br></div><div>
Thanks

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 13, 2022 at 2:30 PM Pradeep Acharya <<a href="mailto:pradeep.acharya1008@gmail.com">pradeep.acharya1008@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi ,</div><div><br></div><div>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. <br></div><div>1.<br></div><div>==1105269== 4,345,040 bytes in 18,532 blocks ar<b>e definitely lost i</b>n loss record 8,466 of 8,480<br>==1105269==    at 0x4C30F0B: malloc (vg_replace_malloc.c:307)<br>==1105269==    by 0x56CAEA0: g_malloc (gmem.c:106)<br>==1105269==    by 0x56E2752: g_slice_alloc (gslice.c:1069)<br>==1105269==    by 0x59DE4EA: default_alloc (in /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)<br>==1105269==    by 0x59EB1C1: gst_buffer_new_allocate (in /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)<br>==1105269==    by 0x1897E9AA: gst_nice_src_read_callback (in /usr/local/lib64/gstreamer-1.0/libgstnice.so)<br>==1105269==    by 0x131C7675: nice_component_emit_io_callback (in /usr/local/lib64/libnice.so.10.11.0)<br>==1105269==    by 0x131C31BC: component_io_cb (in /usr/local/lib64/libnice.so.10.11.0)<br>==1105269==    by 0x6E13A68: socket_source_dispatch (gsocket.c:4007)<br>==1105269==    by 0x56C5320: g_main_dispatch (gmain.c:3325)<br>==1105269==    by 0x56C5320: g_main_context_dispatch (gmain.c:4043)<br>==1105269==    by 0x56C56B7: g_main_context_iterate.isra.23 (gmain.c:4119)<br>==1105269==    by 0x56C5969: g_main_loop_run (gmain.c:4317)</div><div><br></div><div>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<br></div><div><br></div><div>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 <b>appsrc </b>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<br></div><div><br></div><div>==1176192== 9,933 (7,973 direct, 1,960 indirect) bytes in 7 blocks are definitely lost in loss record 9,028 of 9,100<br>==1176192==    at 0x4C30F0B: malloc (vg_replace_malloc.c:307)<br>==1176192==    by 0x56CAEA0: g_malloc (gmem.c:106)<br>==1176192==    by 0x56E2752: g_slice_alloc (gslice.c:1069)<br>==1176192==    by 0x59DE788: _sysmem_copy (in /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)<br>==1176192==    by 0x59EA6E8: gst_buffer_copy_into (in /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)<br>==1176192==    by 0x59ED90F: gst_buffer_copy_deep (in /usr/local/lib64/libgstreamer-1.0.so.0.2100.0)</div><div><br> </div><div>Thanks <br></div><div><br></div></div>
</blockquote></div>