It's been around for more than 4 years and people have built
lots of stuff on top of it, doesn't really make sense to keep
it marked as unstable. We're unlikely to change it now, and
we can always deprecate it and make a new one if needed.
This stabilises the following API:
- gst_tracer_register()
- gst_tracing_get_active_tracers()
- gst_tracing_register_hook()
- gst_tracer_record_new()
- gst_tracer_record_log()
Might also help a bit with #424
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/576>
Fixes the following build error and missing '-pthread' argument when
linking:
subprojects/gstreamer/plugins/tracers/libgstcoretracers.so.p/gstleaks.c.o: In function `gst_leaks_tracer_setup_signals':
/work/build32/../subprojects/gstreamer/plugins/tracers/gstleaks.c:919: undefined reference to `pthread_atfork'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/571>
Use thread-safe accesses to pad peers and parent objects. This
fixes some crashers and all the non-safe access patterns I could
spot. There's still some weirdness when using the latency
tracer on pipeline chains that aren't yet linked, but this
at least stops it segfaulting.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/269>
The signal handlers were performing mutex operations in the signal handlers
which is bad idea that may lead to deadlocks.
1. Implement a separate signal thread to handle the signals.
2. Use the glib provided signal GSource to avoid performing operations in
the signal handler.
Fix#186
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/487>
When the user sets filters, we should not trace ref counts of object that
are not traced. This optimizes the tracer by potentially avoiding
generating useless backtraces.
If the element before the sink needs $n buffers to produce one output
buffer, we were reffing $n events and unreffing only one.
Prevent this by using g_object_set_qdata_full() to handle the event
unreffing so we're sure no ref will be lost.
The records are static and so appear as false positives when using those
tracers with the leaks tracer as well.
The leaks tracer was already setting this flag on its record so let's
set it on the other ones as well.
This feature was previously available only through the SIGUSR2 signal,
which meant it wasn't available on platforms that don't have UNIX
signals, such as Windows and with applications that already use
SIGUSR1 for something else.
Now we have action-signals for doing the same. These action signals
can also be used for fetching the checkpoint information
programmatically instead of printing to the debug log.
This allows programs to inspect the leaked objects directly, log them,
and so on. Unlike the existing mechanism to use SIGUSR1, this also
works on platforms that do not support UNIX signals, such as Windows
and with applications that already use SIGUSR1 for something else.
This will be useful in combination with the next commit when we add
API to get a list of active tracers so that consumers of the API can
easily distinguish tracer objects.
The code implicitly uses this value when the stack trace is not FULL.
Mostly useful for documenting the behaviour when each flag is passed
and for translating to/from strings.
The pad name sotred in the latency event has no longer the name of the element,
so we have to get the element Id, element name and pad name values from the data
structure and compare all 3 values.
First, the event would be leaved, but also when an element takes
several buffers before producing one, we want the reported latency to be
the aggregation, so the distance from the oldest buffer.
This sets back the default to trace only pipeline latency, and add flags
to enabled element tracing. It is now possible to only trace element
latency, only trace pipeline latency, trace both or none.
This removes the passing of pad inside of a GstEvent. While this is not
a bug, it may affect the live time of the pad, hense change the pipeline
behaviour.
The post tracer hooks have a GstQuery argument which was truncated from
the trace. As the post hook is the one that contains the useful data,
this bug was hiding the important information from that trace.
Include the timestamp of the recorded log as in the 'stats' tracer.
This can be useful, for example, to plot a graph showing the latency
over time.
https://bugzilla.gnome.org/show_bug.cgi?id=781315
