After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591045 - [basesrc] Leaking GstTask instances
[basesrc] Leaking GstTask instances
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal blocker
: 0.10.25
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-07 10:44 UTC by Sebastian Dröge (slomo)
Modified: 2009-08-08 20:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2009-08-07 10:44:38 UTC
Hi,
basesrc is leaking GstTask instances with current GIT. This can be reproduced by running the core or base unit tests in valgrind.

Examples of failing tests are core/fakesrc, core/simple-launch-lines, base/adder, base/audioresample, ......

Call stack of the instantiation looks like:
==3707== 351 (256 direct, 95 indirect) bytes in 1 blocks are definitely lost in loss record 2,050 of 2,167
==3707==    at 0x4C2391E: malloc (vg_replace_malloc.c:207)
==3707==    by 0x6182562: g_malloc (gmem.c:131)
==3707==    by 0x61984D7: g_slice_alloc (gslice.c:824)
==3707==    by 0x6198805: g_slice_alloc0 (gslice.c:833)
==3707==    by 0x55BFC9F: g_type_create_instance (gtype.c:1654)
==3707==    by 0x55A3C7A: g_object_constructor (gobject.c:1338)
==3707==    by 0x55A432B: g_object_newv (gobject.c:1215)
==3707==    by 0x55A4EA6: g_object_new_valist (gobject.c:1278)
==3707==    by 0x55A4FEB: g_object_new (gobject.c:1060)
==3707==    by 0x50B6B49: gst_task_create (gsttask.c:326)
==3707==    by 0x508FD21: gst_pad_start_task (gstpad.c:5110)
==3707==    by 0x77EFB9F: gst_base_src_perform_seek (gstbasesrc.c:1356)
==3707==    by 0x77F00B3: gst_base_src_activate_push (gstbasesrc.c:2755)
==3707==    by 0x5095C8A: gst_pad_activate_push (gstpad.c:904)
==3707==    by 0x5096836: gst_pad_set_active (gstpad.c:660)
==3707==    by 0x507886A: activate_pads (gstelement.c:2631)
==3707==    by 0x5089A6D: gst_iterator_fold (gstiterator.c:545)
==3707==    by 0x50787D5: iterator_activate_fold_with_resync (gstelement.c:2663)
==3707==    by 0x507AB6E: gst_element_pads_activate (gstelement.c:2700)
==3707==    by 0x507CD3E: gst_element_change_state_func (gstelement.c:2777)
Comment 1 Wim Taymans 2009-08-07 11:29:48 UTC
It's not really a leak, it's that the unit-test stops before the task thread managed to unref the task. Adding a gst_task_cleanup_all() after the test seems to get rid of the warnings.
Comment 2 Wim Taymans 2009-08-07 11:36:01 UTC
I wonder if we can add gst_task_cleanup_all() in some check hook at the end of the test. Any ideas?
Comment 3 Tim-Philipp Müller 2009-08-07 11:45:12 UTC
You could add it to GST_END_TEST in gstcheck.h
Comment 4 Sebastian Dröge (slomo) 2009-08-08 20:28:35 UTC
commit 165df5e00d31ef582118b4c7e11d284ce179c052
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Sat Aug 8 22:27:06 2009 +0200

    check: Call gst_task_cleanup_all() in GST_END_TEST
    
    This fixes many unit tests under valgrind that shows
    leaking GstTasks that are not really leaked but just
    not unreffed by the task thread before the unit test
    stopped.
    
    Fixes bug #591045.