GNOME Bugzilla – Bug 777440
Ignore leaks in gst_check_init
Last modified: 2017-01-30 14:31:32 UTC
Make valgrind ignore leaks in gst_check_init.
Created attachment 343703 [details] [review] ignore leaks in gst_check_init
Review of attachment 343703 [details] [review]: ::: gst.supp @@ +4044,3 @@ + fun:g_object_new + fun:* + fun:* You can put "..." here instead of multiple lines of * @@ +4049,3 @@ + fun:gst_init + fun:gst_check_init + fun:main main() seems not needed here, also why is this not covered by another leak suppression that is probably there for gst_init / gst_init_check already?
main() is present in other places. Thanks for your comments I'll try to improve my patch.
Created attachment 343713 [details] [review] ignore leaks in gst_check_init
The other suppression cases for gst_init_check ignore other kind of leaks. The "common factor" for all of them is a call stack containing: fun:g_option_context_parse fun:gst_init_check fun:gst_init fun:gst_check_init
Review of attachment 343713 [details] [review]: Didn't we implement gst_deinit() for that one ?
Which commit exactly? We see the leak with 1.10.2.
What exactly is leaked here that is not destroyed in gst_deinit()?
valgrind output: ==4676== 217 (184 direct, 33 indirect) bytes in 1 blocks are definitely lost in loss record 1,756 of 1,823 ==4676== at 0x62875CC: g_type_create_instance (in /tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so.0.4600.2) ==4676== by 0x6269D9A: ??? (in /tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so.0.4600.2) ==4676== by 0x626B590: g_object_newv (in /tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so.0.4600.2) ==4676== by 0x626BE7B: g_object_new (in /tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so.0.4600.2) ==4676== by 0x5B4E76F: ??? (in /tmp/sysroots/x86_64-linux/usr/lib/libgstreamer-1.0.so.0.1002.0) ==4676== by 0x5B49B48: ??? (in /tmp/sysroots/x86_64-linux/usr/lib/libgstreamer-1.0.so.0.1002.0) ==4676== by 0x67025F7: g_option_context_parse (in /tmp/sysroots/x86_64-linux/usr/lib/libglib-2.0.so.0.4600.2) ==4676== by 0x5B4AA1E: gst_init_check (in /tmp/sysroots/x86_64-linux/usr/lib/libgstreamer-1.0.so.0.1002.0) ==4676== by 0x5B4AA66: gst_init (in /tmp/sysroots/x86_64-linux/usr/lib/libgstreamer-1.0.so.0.1002.0) ==4676== by 0x59079F2: gst_check_init (in /home/patricia/products/cvp-unittests/builds/p5515/tmp/sysroots/x86_64-linux/usr/lib/libgstcheck-1.0.so.0.1002.0) ==4676== by 0x404CFB: main (testsrc.c:624)
Can you get another one with debug symbols for GStreamer and GLib/GObject?
==6465== 217 (184 direct, 33 indirect) bytes in 1 blocks are definitely lost in loss record 1,763 of 1,829 | ==6465== at 0x62875DC: g_type_create_instance (in /tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so.0.4600.2) | ==6465== by 0x6269DAA: g_object_new_internal (in /tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so.0.4600.2) | ==6465== by 0x626B5A0: g_object_newv (in /tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so.0.4600.2) | ==6465== by 0x626BE8B: g_object_new (in /tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so.0.4600.2) | ==6465== by 0x5B4E77F: _priv_gst_allocator_initialize (gstallocator.c:594) | ==6465== by 0x5B49B58: init_post (gst.c:576) | ==6465== by 0x67025F7: g_option_context_parse (in /tmp/sysroots/x86_64-linux/usr/lib/libglib-2.0.so.0.4600.2) | ==6465== by 0x5B4AA2E: gst_init_check (gst.c:353) | ==6465== by 0x5B4AA76: gst_init (gst.c:399) | ==6465== by 0x59079F2: gst_check_init (gstcheck.c:127) | ==6465== by 0x404D0B: main (testsrc.c:624) | ==6465==
Is the provided information enough?
This is unreffed again in _priv_gst_allocator_cleanup() by gst_deinit(). So something is actually leaking this (or gst_deinit() is not called), and it's not something for a suppression.
Yes. There is actually an allocator leak in our test code and this leak is visible thanks to the commit 1ea831bd (in gstreamer): commit 1ea831bd6cedbba89e5e78af58976238c89e5b75 Author: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk> Date: Mon Apr 18 13:05:40 2016 +0300 allocator: add cleanup method Make tracking memory leaks easier. https://bugzilla.gnome.org/show_bug.cgi?id=765212 We do not see this leak in GStreamer 1.8.3 because the call to _priv_gst_allocator_cleanup() is missing. Thank you for your help!