GNOME Bugzilla – Bug 580585
rtpmux memleak
Last modified: 2009-04-28 20:31:04 UTC
After switching to latest rtpmuxer / rtpdtmfmux code we have some memleaks : ==00:00:54:46.747 21135== 25,944 bytes in 138 blocks are indirectly lost in loss record 33,229 of 33,236 ==00:00:54:46.747 21135== at 0x4024AEE: malloc (vg_replace_malloc.c:207) ==00:00:54:46.747 21135== by 0x45E0E93: g_malloc (gmem.c:131) ==00:00:54:46.747 21135== by 0x45F77D2: g_slice_alloc (gslice.c:824) ==00:00:54:46.747 21135== by 0x45F7B04: g_slice_alloc0 (gslice.c:833) ==00:00:54:46.747 21135== by 0x4420F27: g_type_create_instance (gtype.c:1555) ==00:00:54:46.747 21135== by 0x4407071: g_object_constructor (gobject.c:1045) ==00:00:54:46.747 21135== by 0x44078FD: g_object_newv (gobject.c:936) ==00:00:54:46.747 21135== by 0x4408581: g_object_new_valist (gobject.c:1026) ==00:00:54:46.747 21135== by 0x44086CD: g_object_new (gobject.c:794) ==00:00:54:46.747 21135== by 0x439ACD2: gst_pad_new_from_template (gstpad.c:512) ==00:00:54:46.747 21135== by 0x64C174E: gst_rtp_mux_request_new_pad (in /usr/local/gstreamer20090301/lib/gstreamer-0.10/libgstrtpmuxer.so) ==00:00:54:46.747 21135== by 0x437EB12: gst_element_get_request_pad (gstelement.c:902) ... also observed : ==00:00:54:46.696 21135== 128 bytes in 2 blocks are still reachable in loss record 33,153 of 33,236 ==00:00:54:46.696 21135== at 0x4024AEE: malloc (vg_replace_malloc.c:207) ==00:00:54:46.696 21135== by 0x4024C6F: realloc (vg_replace_malloc.c:429) ==00:00:54:46.696 21135== by 0x45E0D79: g_realloc (gmem.c:170) ==00:00:54:46.696 21135== by 0x45B1569: g_ptr_array_maybe_expand (garray.c:414) ==00:00:54:46.696 21135== by 0x45B15D9: g_ptr_array_add (garray.c:576) ==00:00:54:46.696 21135== by 0x43750EB: gst_caps_append_structure (gstcaps.c:700) ==00:00:54:46.696 21135== by 0x43758B6: gst_caps_copy (gstcaps.c:282) ==00:00:54:46.696 21135== by 0x64C1CE2: gst_rtp_mux_setcaps (in /usr/local/gstreamer20090301/lib/gstreamer-0.10/libgstrtpmuxer.so) ==00:00:54:46.696 21135== by 0x439503F: gst_pad_set_caps (gstpad.c:2426) ==00:00:54:46.696 21135== by 0x4395C0A: gst_pad_configure_sink (gstpad.c:2480) ==00:00:54:46.696 21135== by 0x4395E71: gst_pad_chain_unchecked (gstpad.c:3875) ==00:00:54:46.696 21135== by 0x439711C: gst_pad_push (gstpad.c:4057) ==00:00:54:46.696 21135== by 0x468CB89: gst_basertppayload_push (gstbasertppayload.c:683) ==00:00:54:46.696 21135== by 0x468B692: gst_base_rtp_audio_payload_push (gstbasertpaudiopayload.c:618) ==00:00:54:46.696 21135== by 0x468C03C: gst_base_rtp_audio_payload_handle_buffer (gstbasertpaudiopayload.c:522) ...
in rtpmux.c:gst_rtp_mux_setcaps() the code changed from : ret = gst_pad_set_caps (rtp_mux->srcpad, caps); gst_caps_unref (caps); To ret = gst_pad_set_caps (rtp_mux->srcpad, caps); if (ret) gst_caps_replace (&padpriv->out_caps, caps); else gst_caps_unref (caps); Shouldn't the gst_caps_unref be done every time, as gst_caps_replace() increases caps refcount ?
In same_clock_rate_fold () ... return !gst_caps_is_empty (intersect); } Shouldn't intersect be unreffed ?
The first patch is good. (In reply to comment #2) > return !gst_caps_is_empty (intersect); > Shouldn't intersect be unreffed ? This one is actually correct, because the g_value_take_boxed() already ate the reference. The second leak is because the fold function didn't unref the pad after using it. Also has been fixed in git..