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

[Sanjay Gupta]

Additional note on gstreamer version: I am using gstreamer version 1.8.1.

On Thu, Sep 8, 2016 at 1:03 PM, Sanjay Gupta <sanjayg417 at gmail.com> wrote:

> Hi,
> Valgrind is showing memory leak in my gstreamer element for which code
> snippet is given below.
>
> *Code snippet:*
>
> 1 #define gst_ssm_playback_parent_class parent_class
> 2 G_DEFINE_TYPE (GstSsmPlayback, gst_ssm_playback, GST_TYPE_ELEMENT);
> 3
> 4 static GstStaticPadTemplate src_factory = GST_STATIC_PAD_TEMPLATE ("src",
> 5    GST_PAD_SRC, GST_PAD_ALWAYS,
> 6    GST_STATIC_CAPS (<some valid caps string>)
> 7    );
> 8
> 9  static void gst_ssm_playback_class_init (GstSsmPlaybackClass * klass)
> 10 {
> 11    GObjectClass*    gobject_class = (GObjectClass *) klass;
> 12    GstElementClass* ssm_ply_element_class = (GstElementClass *) klass;
> 13    [...]
> 14    gst_element_class_add_pad_template (ssm_ply_element_class, *gst_static_pad_template_get
> (&src_factory));*
> 15    [...]
> 16    gobject_class->finalize = gst_ssm_playback_finalize;
> 17    gobject_class->dispose  = gst_ssm_playback_dispose;
> 18    [...]
> 19 }
> 20 static void gst_ssm_playback_init (GstSsmPlayback *ssmPlyElem)
> 21 {
> 22    [...]
> 23    *ssmPlyElem->srcPad = gst_pad_new_from_static_template
> (&src_factory, "src");*
> 24    *ret = gst_element_add_pad (GST_ELEMENT (ssmPlyElem),
> ssmPlyElem->srcPad);*
> 25 }
> 26
>
> 27 static void gst_ssm_playback_dispose(GObject * object)
> 28 {
> 29      [...]
> 30    if (ssmPlyElem->srcPad)
> 31       * gst_element_remove_pad(GST_ELEMENT (ssmPlyElem),
> ssmPlyElem->srcPad);*
> 32
> 33     G_OBJECT_CLASS(parent_class)->dispose (object);
> 34 }
>
> 35 static void gst_ssm_playback_finalize(GObject * object)
> 36 {
> 37     [...]
> 38    G_OBJECT_CLASS(parent_class)->finalize (object);
> 39 }
>
> I have the following queries and can you please provide your input on this
> please?
> *Q1*. As shown in Line#14 in code snippet above, should I *unref* pad
> template object passed in *gst_element_class_add_pad_template()* API?
>        As per my understanding, it will initially have floating reference
> and once we pass this object to API *gst_element_class_add_pad_template()*,
> this API will own pad template object and no need to unref it in the
> element. Not sure why valgrind is showing this as leak even though
> dispose/finalize API of this object is called. See below for call stack.
>
> ==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)
>
> *Q2*.  We are creating a source pad in line#23 and adding to the element
> in Ln#24 in code snippet above. As per my understanding, API *gst_element_add_pad
> *takes the ownership of the pad object.
> Even though dispose/finalize APIs are called and also we are removing this
> pad from element using gst_element_remove_pad() in dispose function but
> valgrind is still showing it as leak. We are also chaining the parent's
> dispose & finalize functions. can you please provide your input on this?
>
> ==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)*
>
>
> ==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)
>
> Thanks a lot in advance for your input/suggestion.
>
> Thanks & Regards,
> Sanjay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160908/5dea77da/attachment-0001.html>