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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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 <[hidden email]> 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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sanjay Gupta]

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 <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sanjay Gupta]

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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel