Need input on memory leak shown by valgrind in my element.

[Sebastian Dröge]

On Thu, 2016-09-08 at 13:03 +0530, Sanjay Gupta wrote:
> 
> ==424== 4 bytes in 1 blocks are still reachable in loss record 126 of
> 7,797
> ==424==    at 0x482F654: malloc (vg_replace_malloc.c:296)
> ==424==    by 0x4C55EA0: g_malloc (gmem.c:97)
> ==424==    by 0x4C6EA54: g_memdup (gstrfuncs.c:384)
> ==424==    by 0x4FBACDC: g_signal_newv (gsignal.c:1661)
> ==424==    by 0x4FBB2D8: g_signal_new_valist (gsignal.c:1831)
> ==424==    by 0x4FBB3CC: g_signal_new (gsignal.c:1373)
> ==424==    by 0x4B25C70: gst_pad_template_class_init
> (gstpadtemplate.c:146)
> ==424==    by 0x4B25C70: gst_pad_template_class_intern_init
> (gstpadtemplate.c:127)
> ==424==    by 0x4FC2E98: type_class_init_Wm (gtype.c:2236)
> ==424==    by 0x4FC2E98: g_type_class_ref (gtype.c:2951)
> ==424==    by 0x4FAD0D0: g_object_new_valist (gobject.c:1959)
> ==424==    by 0x4FAD5AC: g_object_new (gobject.c:1617)
> ==424==    by 0x4B26438: gst_static_pad_template_get
> (gstpadtemplate.c:281)
> ==424==    by 0x8083814: gst_otv_ssm_playback_class_init
> (gstssmplayback.c:3895)

This is not a memory leak in the traditional sense but a one-time
allocation that is never freed because it exists forever. It's per-
class data.

> ==441== 4,377 (36 direct, 4,341 indirect) bytes in 3 blocks are
> definitely lost in loss record 8,528 of 8,612
> ==441== at 0x482F654: malloc (vg_replace_malloc.c:296)
> ==441== by 0x4C5AE90: g_malloc (gmem.c:97)
> ==441== by 0x4C71AE8: g_slice_alloc (gslice.c:1009)
> ==441== by 0x4C4F49C: g_list_append (glist.c:261)
> ==441== by 0x4B00150: gst_element_add_pad (gstelement.c:698)
> ==441== by 0x13E09CD0: gst_ssm_playback_init
> (gstotvssmplayback.c:4165)

This is a real leak, but other than you guess it is not the pad that is
leaked here but the element with the pad. gst_element_add_pad() is
adding the pad to a list inside the pad, adding a list node causes the
allocation above and the list is never freed. It would be freed in
GstElement's dispose().

So somewhere there is a leak of your element.


Also you don't have to remove the pad in dispose() yourself, GstElement
already does that for you. You only have to remove pads if they are to
be removed at an earlier time.

> ==441== 18,967 (4,004 direct, 14,963 indirect) bytes in 13 blocks are
> definitely lost in loss record 8,569 of 8,612
> ==441== at 0x4FC9B0C: g_type_create_instance (gtype.c:1848)
> ==441== by 0x4FAFF7C: g_object_new_internal (gobject.c:1774)
> ==441== by 0x4FB2230: g_object_new_valist (gobject.c:2033)
> ==441== by 0x4FB258C: g_object_new (gobject.c:1617)
> ==441== by 0x4B20C34: gst_pad_new_from_template (gstpad.c:857)
> ==441== by 0x4B20C8C: gst_pad_new_from_static_template (gstpad.c:882)
> ==441== by 0x13E09C04: gst_ssm_playback_init
> (gstotvssmplayback.c:4155)

This is the actual pad being leaked.


So in summary, something outside your element or in the code that you
didn't show is not doing the reference counting with the pad and
element correctly. The whole element and the pad are leaked, but not
because of anything in the code you showed.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160910/d8bac796/attachment.sig>