[Bug 733187] integrating the tracer branch
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Mar 31 09:45:38 PDT 2015
https://bugzilla.gnome.org/show_bug.cgi?id=733187
--- Comment #24 from Julien Isorce <julien.isorce at gmail.com> ---
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)
2- In the draft you mentioned "We'll wrap interesting api calls with two
macros" but it does not necessarly work by pairs right ?
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 ?
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 ?
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 ?
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 ?)
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.
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.
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.
More information about the gstreamer-bugs
mailing list