<div dir="ltr">Hi Sebastian,<div>Thanks for your input. Finally I figured out this memory leak and fixed it. Issue was in my code as you pointed out.</div><div>I missed to unref a pad template at one place which I got with API gst_pad_get_pad_template(pad). Thanks a lot for help.</div><div><br></div><div>Thanks & Regards,</div><div>Sanjay <br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 10, 2016 at 1:46 PM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 2016-09-08 at 13:03 +0530, Sanjay Gupta wrote:<br>
> <br>
> ==424== 4 bytes in 1 blocks are still reachable in loss record 126 of<br>
> 7,797<br>
> ==424==    at 0x482F654: malloc (vg_replace_malloc.c:296)<br>
> ==424==    by 0x4C55EA0: g_malloc (gmem.c:97)<br>
> ==424==    by 0x4C6EA54: g_memdup (gstrfuncs.c:384)<br>
> ==424==    by 0x4FBACDC: g_signal_newv (gsignal.c:1661)<br>
> ==424==    by 0x4FBB2D8: g_signal_new_valist (gsignal.c:1831)<br>
> ==424==    by 0x4FBB3CC: g_signal_new (gsignal.c:1373)<br>
> ==424==    by 0x4B25C70: gst_pad_template_class_init<br>
> (gstpadtemplate.c:146)<br>
> ==424==    by 0x4B25C70: gst_pad_template_class_intern_<wbr>init<br>
> (gstpadtemplate.c:127)<br>
> ==424==    by 0x4FC2E98: type_class_init_Wm (gtype.c:2236)<br>
> ==424==    by 0x4FC2E98: g_type_class_ref (gtype.c:2951)<br>
> ==424==    by 0x4FAD0D0: g_object_new_valist (gobject.c:1959)<br>
> ==424==    by 0x4FAD5AC: g_object_new (gobject.c:1617)<br>
> ==424==    by 0x4B26438: gst_static_pad_template_get<br>
> (gstpadtemplate.c:281)<br>
> ==424==    by 0x8083814: gst_otv_ssm_playback_class_<wbr>init<br>
> (gstssmplayback.c:3895)<br>
<br>
</span>This is not a memory leak in the traditional sense but a one-time<br>
allocation that is never freed because it exists forever. It's per-<br>
class data.<br>
<span class=""><br>
> ==441== 4,377 (36 direct, 4,341 indirect) bytes in 3 blocks are<br>
> definitely lost in loss record 8,528 of 8,612<br>
> ==441== at 0x482F654: malloc (vg_replace_malloc.c:296)<br>
> ==441== by 0x4C5AE90: g_malloc (gmem.c:97)<br>
> ==441== by 0x4C71AE8: g_slice_alloc (gslice.c:1009)<br>
> ==441== by 0x4C4F49C: g_list_append (glist.c:261)<br>
> ==441== by 0x4B00150: gst_element_add_pad (gstelement.c:698)<br>
> ==441== by 0x13E09CD0: gst_ssm_playback_init<br>
> (gstotvssmplayback.c:4165)<br>
<br>
</span>This is a real leak, but other than you guess it is not the pad that is<br>
leaked here but the element with the pad. gst_element_add_pad() is<br>
adding the pad to a list inside the pad, adding a list node causes the<br>
allocation above and the list is never freed. It would be freed in<br>
GstElement's dispose().<br>
<br>
So somewhere there is a leak of your element.<br>
<br>
<br>
Also you don't have to remove the pad in dispose() yourself, GstElement<br>
already does that for you. You only have to remove pads if they are to<br>
be removed at an earlier time.<br>
<span class=""><br>
> ==441== 18,967 (4,004 direct, 14,963 indirect) bytes in 13 blocks are<br>
> definitely lost in loss record 8,569 of 8,612<br>
> ==441== at 0x4FC9B0C: g_type_create_instance (gtype.c:1848)<br>
> ==441== by 0x4FAFF7C: g_object_new_internal (gobject.c:1774)<br>
> ==441== by 0x4FB2230: g_object_new_valist (gobject.c:2033)<br>
> ==441== by 0x4FB258C: g_object_new (gobject.c:1617)<br>
> ==441== by 0x4B20C34: gst_pad_new_from_template (gstpad.c:857)<br>
> ==441== by 0x4B20C8C: gst_pad_new_from_static_<wbr>template (gstpad.c:882)<br>
> ==441== by 0x13E09C04: gst_ssm_playback_init<br>
> (gstotvssmplayback.c:4155)<br>
<br>
</span>This is the actual pad being leaked.<br>
<br>
<br>
So in summary, something outside your element or in the code that you<br>
didn't show is not doing the reference counting with the pad and<br>
element correctly. The whole element and the pad are leaked, but not<br>
because of anything in the code you showed.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a></font></span><br>______________________________<wbr>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.<wbr>freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-<wbr>devel</a><br>
<br></blockquote></div><br></div></div></div>