GNOME Bugzilla – Bug 749427
Dispose/finalize GST_REFCOUNTING log messages missing poitner of object being disposed/finalized
Last modified: 2016-04-02 17:21:40 UTC
When GST_REFCOUNTING is enabled, it logs object creation, dispose and finalization. This is useful for identifying memory leaks in applications that have not disposed of GStreamer objects correctly. Currently, the dispose and finalize log messages do not log the address of the object that they are disposing/finalizing (as shown by the example GST_REFCOUNTING log lines below): 0:00:00.143050214 2886 0x2215a60 TRACE GST_REFCOUNTING gstobject.c:280:gst_object_unref:<pipeline> 0x2232120 unref 1->0 0:00:00.143058808 2886 0x2215a60 TRACE GST_REFCOUNTING gstobject.c:369:gst_object_dispose:<pipeline> dispose 0:00:00.143066542 2886 0x2215a60 TRACE GST_REFCOUNTING gstobject.c:411:gst_object_finalize:<pipeline> finalize 0:00:00.143073872 2886 0x2215a60 TRACE GST_REFCOUNTING gstobject.c:769:gst_object_unparent:<bin> unparent 0:00:00.143080301 2886 0x2215a60 TRACE GST_REFCOUNTING gstobject.c:280:gst_object_unref:<bin> 0x2232040 unref 1->0 0:00:00.143088379 2886 0x2215a60 TRACE GST_REFCOUNTING gstobject.c:369:gst_object_dispose:<bin> dispose 0:00:00.143095991 2886 0x2215a60 TRACE GST_REFCOUNTING gstobject.c:411:gst_object_finalize:<bin> finalize 0:00:00.143109050 2886 0x2215a60 TRACE GST_REFCOUNTING gstobject.c:411:gst_object_finalize:<registry0> finalize This makes it very difficult to match up object allocation/dispose/finalize log messages without "guessing/calculating" which dispose/finalize log messages are for which objects
Created attachment 303422 [details] [review] Patch that adds address logging to GST_REFCOUNTING dispose and finalize log messages With this patch the dispose and finalize GST_REFCOUNTING log messages include the address of the object that is being disposed/finalized. An example is shown below: 0:00:00.086486944 5872 0x205aa60 TRACE GST_REFCOUNTING gstobject.c:280:gst_object_unref:<pipeline> 0x2077120 unref 1->0 0:00:00.086495187 5872 0x205aa60 TRACE GST_REFCOUNTING gstobject.c:369:gst_object_dispose:<pipeline> 0x2077120 dispose 0:00:00.086503724 5872 0x205aa60 TRACE GST_REFCOUNTING gstobject.c:411:gst_object_finalize:<pipeline> 0x2077120 finalize 0:00:00.086511643 5872 0x205aa60 TRACE GST_REFCOUNTING gstobject.c:769:gst_object_unparent:<bin> unparent 0:00:00.086518240 5872 0x205aa60 TRACE GST_REFCOUNTING gstobject.c:280:gst_object_unref:<bin> 0x2077040 unref 1->0 0:00:00.086526440 5872 0x205aa60 TRACE GST_REFCOUNTING gstobject.c:369:gst_object_dispose:<bin> 0x2077040 dispose 0:00:00.086534906 5872 0x205aa60 TRACE GST_REFCOUNTING gstobject.c:411:gst_object_finalize:<bin> 0x2077040 finalize 0:00:00.086548727 5872 0x205aa60 TRACE GST_REFCOUNTING gstobject.c:411:gst_object_finalize:<registry0> 0x205f150 finalize With the above change to the logging, a simple grep on an address will list all GST_REFCOUNTING log messages for that object.
Review of attachment 303422 [details] [review]: ::: gst/gstpipeline.c @@ -225,3 +225,3 @@ GstClock **clock_p = &pipeline->fixed_clock; - GST_CAT_DEBUG_OBJECT (GST_CAT_REFCOUNTING, pipeline, "dispose"); + GST_CAT_DEBUG_OBJECT (GST_CAT_REFCOUNTING, pipeline, "%p dispose", pipeline); This is suspiciously redundant. The log in GstObject should be enough imho. Any idea ?
My reaction was the same as Nicolas initially, so I looked at whether to remove some of those other trace statements, but ultimately decided against it, since it's still useful to see them before other things take place (which the GstObject one wouldn't be). We can still remove any superfluous log messages later, so just pushed it as is for now. Thanks for the patch! commit b8f2929dac4a47a11a476057c3adc1920a97ac6d Author: Mark Combellack <gnome-bugzilla@combellack.net> Date: Fri May 15 13:36:04 2015 +0100 GST_REFCOUNTING: Add logging of pointer address for dispose, finalize, etc messages Updated the GST_REFCOUNTING logging so that it includes the pointer address of the object that is being disposed or finalized. With this change is is then possible to match up GST_REFCOUNTING log messages for object allocation/disposal/finalization. This can help with diagnosing "memory leaks" in applications that have not correctly disposed of all the GStreamer objects it creates. https://bugzilla.gnome.org/show_bug.cgi?id=749427