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

Sanjay Gupta sanjayg417 at gmail.com
Fri Sep 9 19:30:29 UTC 2016


Hi,
can someone clarify on this please? Thanks a ton in advance.

Thanks & Regards,
Sanjay

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

> 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/20160910/45acd3ea/attachment-0001.html>


More information about the gstreamer-devel mailing list