GNOME Bugzilla – Bug 543961
Memory leak in gst.Bin.do_handle_message
Last modified: 2008-12-09 10:16:39 UTC
Please describe the problem: Overloading do_handle_message cause a memory leak on message (and associated structure). Steps to reproduce: 1. launch the attached python file Actual results: a launch under valgrind cause the following output : ==12618== 5,960 bytes in 116 blocks are possibly lost in loss record 34 of 48 ==12618== at 0x4022765: malloc (vg_replace_malloc.c:149) ==12618== by 0x4708AF5: g_malloc (in /usr/lib/libglib-2.0.so.0.1400.1) ==12618== by 0x471D50A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1400.1) ==12618== by 0x471DBE4: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1400.1) ==12618== by 0x4591536: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.1400.1) ==12618== by 0x44F6424: gst_mini_object_new (gstminiobject.c:181) ==12618== by 0x44F54B9: gst_message_new_custom (gstmessage.c:278) ==12618== by 0x44F571B: gst_message_new_element (gstmessage.c:690) ==12618== by 0x4A43210: gst_udpsrc_create (gstudpsrc.c:449) ==12618== by 0x44A64F4: gst_push_src_create (gstpushsrc.c:117) ==12618== by 0x4498930: gst_base_src_get_range (gstbasesrc.c:1779) ==12618== by 0x449C430: gst_base_src_loop (gstbasesrc.c:1985) ==12618== ==12618== ==12618== 7,793,891 (1,180,840 direct, 6,613,051 indirect) bytes in 59,042 blocks are definitely lost in loss record 44 of 48 ==12618== at 0x4021AA4: calloc (vg_replace_malloc.c:279) ==12618== by 0x4708A5D: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1400.1) ==12618== by 0x45100BA: gst_structure_id_empty_new_with_size (gststructure.c:116) ==12618== by 0x45106B5: gst_structure_new_valist (gststructure.c:238) ==12618== by 0x4510731: gst_structure_new (gststructure.c:209) ==12618== by 0x4A43201: gst_udpsrc_create (gstudpsrc.c:449) ==12618== by 0x44A64F4: gst_push_src_create (gstpushsrc.c:117) ==12618== by 0x4498930: gst_base_src_get_range (gstbasesrc.c:1779) ==12618== by 0x449C430: gst_base_src_loop (gstbasesrc.c:1985) ==12618== by 0x4516815: gst_task_func (gsttask.c:192) ==12618== by 0x47260C7: (within /usr/lib/libglib-2.0.so.0.1400.1) ==12618== by 0x47245AE: (within /usr/lib/libglib-2.0.so.0.1400.1) ==12618== ==12618== ==12618== 2,866,068 (1,302,960 direct, 1,563,108 indirect) bytes in 21,716 blocks are definitely lost in loss record 47 of 48 ==12618== at 0x4022765: malloc (vg_replace_malloc.c:149) ==12618== by 0x4708AF5: g_malloc (in /usr/lib/libglib-2.0.so.0.1400.1) ==12618== by 0x471D50A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1400.1) ==12618== by 0x471DBE4: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1400.1) ==12618== by 0x4591536: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.1400.1) ==12618== by 0x44F6424: gst_mini_object_new (gstminiobject.c:181) ==12618== by 0x44F54B9: gst_message_new_custom (gstmessage.c:278) ==12618== by 0x44F571B: gst_message_new_element (gstmessage.c:690) ==12618== by 0x4A43210: gst_udpsrc_create (gstudpsrc.c:449) ==12618== by 0x44A64F4: gst_push_src_create (gstpushsrc.c:117) ==12618== by 0x4498930: gst_base_src_get_range (gstbasesrc.c:1779) ==12618== by 0x449C430: gst_base_src_loop (gstbasesrc.c:1985) Expected results: Does this happen every time? Other information:
Created attachment 114910 [details] python test file
ok, so this is all related to methods 'stealing' references. with gst.Bin.handle_message you might be using it in two different ways. * Either you create a *new* message from python within that method, in which case you will indeed need the C wrapper (GstBin__do_handle_message in gstbin.override) to increment the refcount of the miniobject before calling the parent function in order for the Python miniobject wrapper to still have its reference against the C miniobject... *.. or you will be just re-using the message given to you, which has already gone under the assumption that the reference will be stolen. The override only assumes the first case (in which case in adds a reference). If you use the code as in the second case... there will be a reference too much => it leaks. Will need to think a bit more on how to solve this issue.
Note: replacing the callback function with this new one in the python test file cause an intantaneous crash : def print_message_cb(bus, message): import time time.sleep(2) print message
Created attachment 124166 [details] [review] fix for the memory leak.
Forget about the comment #3 which is due to a missing gobject.threads_init(). The proposed patch fix the memory leak in the binding. In fact, it is an extra gst_mini_object_ref() in the cleanup function in arg-types.py generator.
2008-12-09 Edward Hervey <edward.hervey@collabora.co.uk> Patch by : Vincent Genieux <mutex at runbox dot com> * gst/arg-types.py: Fix memory leak for GstMiniObjects used as parameters in class method overrides. Fixes #543961