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

Sanjay Gupta sanjayg417 at gmail.com
Mon Nov 7 12:37:31 UTC 2016


Hi Sebastian,
Thanks for your input. Finally I figured out this memory leak and fixed it.
Issue was in my code as you pointed out.
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.

Thanks & Regards,
Sanjay

On Sat, Sep 10, 2016 at 1:46 PM, Sebastian Dröge <sebastian at centricular.com>
wrote:

> 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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161107/5718a291/attachment-0001.html>


More information about the gstreamer-devel mailing list