[Bug 733187] integrating the tracer branch

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=733187

--- Comment #25 from Stefan Sauer (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> ---
(In reply to Julien Isorce from comment #24)
> Hi, I am trying to understand this new feature, some questions came up:
> 
> 1- There is hard coded relation between PRE/POST, it is up to the GstTracer
> plugin to make the relation right ? (So the tracer can only hook all the PRE
> without the POST if it wants)

Yes it is hardcoded and it is mostly meant to log return values as well.

> 
> 2- In the draft you mentioned  "We'll wrap interesting api calls with two
> macros" but it does not necessarly work by pairs right ?

Yes void methods would not need a 2nd entry and there could be api entries
where we want to have 3 hook if we'd need to track some inbetween state. I did
not come across such one so far though.

> 
> 3- In the draft you mentioned "I'd like to know about ref-counts of parts in
> the pipeline to find ref-count issues" but there is no such hook for the
> moment right ?

That part is an attempt what people would like to do with tracing data. I did
not received a lot of contributions here though.

> 
> 4- With such hook GST_TRACER_OBJECT_REF / GST_TRACER_OBJECT_UNREF there is
> no PRE/POST wording and these hooks are not surrounding a specific function,
> would this be still valid ?

The main issues with refcounts is that we'd need to do this in glib and not in
gstreamer.

> 
> 5- Then I am a bit confused, if such ref/unref hook exist, it will replace
> "GST_CAT_TRACE_OBJECT (GST_CAT_REFCOUNTING," in gst_object_ref /
> gst_object_unref ? Actually it will allow to a GstTracer to match refs with
> unrefs ?

Yes, tracing can often replace logging. Matching unref to refs is tricky. One
can figure easily whether the refs and unrefs are balanced, but if not, there
is not easy way to point to where the imbalance comes from.

> 
> 6- Could
> _gst_alloc_trace_new/_gst_alloc_trace_free/(_gst_alloc_trace_register) be
> replaced by GST_TRACER_OBJECT_NEW / GST_TRACER_OBJECT_FREE ? (live/mem-live,
> and replace all the _gst_alloc_trace api in general ?)

These are deprecated. I believe we consider dropping them in 2.0.

> 
> 7- Would it be possible to add support to print the backtrace of the hooks
> from a GstTracer ? parenting hierachy ? And who own a ref on a "traced"
> object ?
> It would give some hints to fin ref-count issues.

glib has support for backtraces, but it is weak. There are solutions to get gcc
style backtraces, but they are all 1) complicatied and 2) not very portable :/

> 
> I guess most of the answers will be yes but not sure :)
> 
> In the draft you mentioned "opengl", indeed that would be awesome to have
> some hooks in GstGL. I can give a try in the future.

I think this is one thing holding the merge back, getting some testing to use
this outside of the core.

> 
> Thx for this feature, can't wait it to be merged!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.