GNOME Bugzilla – Bug 746541
glimagesink memleak
Last modified: 2015-03-22 18:13:25 UTC
Created attachment 299974 [details] [review] fix caps leak fix caps leak
valgrind show also this leak ==9662== 72 bytes in 1 blocks are definitely lost in loss record 1,580 of 2,289 ==9662== at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9662== by 0x58F9289: g_malloc (in /usr/lib/libglib-2.0.so.0.4200.2) ==9662== by 0x591000F: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.4200.2) ==9662== by 0x59105DD: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.4200.2) ==9662== by 0x5937D9E: ??? (in /usr/lib/libglib-2.0.so.0.4200.2) ==9662== by 0x591A4EE: ??? (in /usr/lib/libglib-2.0.so.0.4200.2) ==9662== by 0x591A5A7: g_thread_new (in /usr/lib/libglib-2.0.so.0.4200.2) ==9662== by 0x97B4794: gst_gl_context_create (gstglcontext.c:928) ==9662== by 0x957673B: _ensure_gl_setup (gstglimagesink.c:744) ==9662== by 0x9578566: gst_glimage_sink_set_caps (gstglimagesink.c:1088) ==9662== by 0x90A65CA: gst_base_sink_default_event (gstbasesink.c:3083) ==9662== by 0x90A1D0C: gst_base_sink_event (gstbasesink.c:3189) ==9662== by 0x4E9D2C7: gst_pad_send_event_unchecked (gstpad.c:5296) ==9662== by 0x4E9D99E: gst_pad_push_event_unchecked (gstpad.c:4983) ==9662== by 0x4E9DF3F: push_sticky (gstpad.c:3590) ==9662== by 0x4E9BEEC: events_foreach (gstpad.c:583) ==9662== by 0x4EA6E0F: check_sticky (gstpad.c:3646) ==9662== by 0x4EA6E0F: gst_pad_push_event (gstpad.c:5108) ==9662== by 0x90BBE7F: gst_pad_set_caps (gstcompat.h:55) ==9662== by 0x90BBE7F: gst_base_transform_setcaps (gstbasetransform.c:1391) ==9662== by 0x90BCE5C: gst_base_transform_sink_eventfunc (gstbasetransform.c:1904) ==9662== by 0x4E9D2C7: gst_pad_send_event_unchecked (gstpad.c:5296) you can reproduce with: videotestsrc ! glimagesink
Review of attachment 299974 [details] [review]: Looks good. Thx for the patch. commit 0719c8c7665658a65e0927e017e600c577d40195 Author: Nicola Murino <nicola.murino@gmail.com> Date: Fri Mar 20 18:33:45 2015 +0100 glimagesink: fix caps leak https://bugzilla.gnome.org/show_bug.cgi?id=746541
thanks for committing, remain the other leak reported above, actually I don't have time to investigate further
Ah sorry I missed this part. I made a quick investigation, breaking on gst_gl_context_create then on g_thread_new then g_slice_alloc0 provides the following backtrace:
+ Trace 234877
Which matches what valgrind gave you (+ the 2 missing ???, g_thread_new_internal and g_system_thread_new) Then the g_slice_alloc0 seems to be the "g_slice_new0 (GThreadPosix)" here https://git.gnome.org/browse/glib/tree/glib/gthread-posix.c?h=glib-2-42#n1154 And we join the thread in gst_gl_context_finalize we should unref it internally: "g_thread_join() consumes the reference to the passed-in thread" I have not valgrind with macports since I upgraded to osx 10.10. If you find more infos please open a new bug since this one was for the first leak. Also please attach the full valgrind output. Thx!
-we should unref / + which should unref
Ah we also use g_thread_ref / g_thread_unref, we are maybe missing a g_thread_unref.
I had another look and just let you know I found the leak. I'll submit it later though.
commit d35e3b84817db5b5c6c79a1f23838096d9529e0e Author: Julien Isorce <j.isorce@samsung.com> Date: Sun Mar 22 19:03:19 2015 +0100 gldisplay: fix GThread leak https://bugzilla.gnome.org/show_bug.cgi?id=746541