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

[Sanjay Gupta]

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/a156666c/attachment.html>