We use to display the latency of each element in random order which is
not very convenient when comparing latency between different runs.
Sort them by "first activity" (the first latency reported for each
element) so it's consistent betwen runs.
This is the same logic when sorting and displaying element stats.
In the hotdoc inspector for example, pads are instantiated with
g_object_new, other code paths to get/set properties already make
that check.
And update doc cache
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.
Needs a valgrind suppression for:
==11119== Warning: invalid file descriptor -1 in syscall close()
==11119== Warning: invalid file descriptor -1 in syscall close()
==11119== Syscall param write(buf) points to uninitialised byte(s)
==11119== at 0x4C4AFAD: syscall (in /usr/lib64/libc-2.29.so)
==11119== by 0x4E70DF9: write_validate (Ginit.c:112)
==11119== by 0x4E70DF9: UnknownInlinedFun (Ginit.c:148)
==11119== by 0x4E70DF9: mincore_validate (Ginit.c:131)
==11119== by 0x4E70CC3: UnknownInlinedFun (Ginit.c:208)
==11119== by 0x4E70CC3: access_mem (Ginit.c:242)
==11119== by 0x4E75536: UnknownInlinedFun (libunwind_i.h:168)
==11119== by 0x4E75536: apply_reg_state (Gparser.c:863)
==11119== by 0x4E75A71: _ULx86_64_dwarf_step (Gparser.c:952)
==11119== by 0x4E71BD3: _ULx86_64_step (Gstep.c:71)
==11119== by 0x48BAF47: generate_unwind_trace (gstinfo.c:2726)
==11119== by 0x48BC92E: gst_debug_get_stack_trace (gstinfo.c:2908)
==11119== by 0x49B2BB2: handle_object_created.part.0 (gstleaks.c:384)
==11119== by 0x488134E: gst_object_constructed (gstobject.c:141)
==11119== by 0x49EC61B: g_object_new_internal (gobject.c:1845)
==11119== by 0x49EE347: g_object_new_valist (gobject.c:2128)
==11119== by 0x49EE69C: g_object_new (gobject.c:1648)
==11119== by 0x48CA59D: gst_pad_new_from_template (gstpad.c:867)
==11119== by 0x68C209E: gst_base_src_init (gstbasesrc.c:454)
==11119== by 0x4A0A0C3: g_type_create_instance (gtype.c:1858)
==11119== by 0x49EC42C: g_object_new_internal (gobject.c:1805)
==11119== by 0x49EDB14: g_object_new_with_properties (gobject.c:1973)
==11119== by 0x49EE6C0: g_object_new (gobject.c:1645)
==11119== by 0x48AF91A: gst_element_factory_create (gstelementfactory.c:372)
==11119== Address 0x1ffeffe000 is on thread 1's stack
==11119== in frame #6, created by generate_unwind_trace (gstinfo.c:2695)
Fixed in libunwind commit:
b256722d49
Needs a separate suppression for Debian because the callstack is
different there.
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 the next commit where we add action-signals on
the leaks tracer to get information about leaks and to manipulate
checkpoints as a replacement for the SIGUSR1 and SIGUSR2 signals for
doing the same.
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 offset in gst_buffer_resize() is additive. So to move back the
offset to zero, we need to pass the opposite of the current offset. This
was raised through the related unit test failingon 32bit as on 64bit
the alignment padding was enough to hide the issue. The test was
modified to also fail on 64bit. This patch will remove spurious
assertions like:
assertion 'bufmax >= bufoffs + offset + size' failed
Fixes#316
It's not really possible for us to recover when someone uses the
gst_tracer_record_new() API incorrectly. Also, document a piece of
somewhat-obscure code.
strcmp() does not allow the arguments to be NULL, but g_strcmp0()
does, so document that we use g_strcmp0() so that people don't need to
worry about that.
Ensure that the code paths for HAVE_UNWIND and HAVE_DBGHELP are never
taken at the same time, even if the build file code changes.
Prefer DbgHelp over libunwind on Windows in case both are somehow
available because DbgHelp is only available when building with the
MSVC toolchain, and libunwind won't give us debug symbols from objects
built with the MSVC toolchain.
Also, print slightly more useful messages for the level of stack trace
support enabled, and document what each if conditional does.
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.
When using GStreamer with Universal Windows Platform apps, dynamic
plugins can only be loaded by filename (without a path) using
gst_plugin_load_file() which will call into g_module_open().
On Windows, GModule calls LoadLibrary() on the filename, but with
UWP we need to use LoadPackagedLibrary() which is basically the same
as LoadLibrary(), except it looks only for DLLs (by name) that have
been packaged as assets with the app.
These assets are not files and cannot be accessed using normal file
APIs such as open() or stat().
The upstream glib merge request for adding LoadPackagedLibrary support
is: https://gitlab.gnome.org/GNOME/glib/merge_requests/951
NOTE: Whitespcae removal is to make gst-indent happy
At the moment, we can only use crank if the pending entry is in the
future. This patch leaves the clock time to the same point if the
pending entry was in the past. This still execute a single entry. This
will be needed for the jitterbuffer, since as soon as we stop waking up
the jitterbuffer when the timer is reschedule later, we may endup with
such case in the unit tests.
Related to #608
There was a race where we could still get the pad event function
called when its private member were already unset, leading to
a segfault in the event handler:
```
0 gst_multi_queue_src_event (pad=<optimized out>, parent=<optimized out>, event=0x7f3ff0007600) at ../subprojects/gstreamer/plugins/elements/gstmultiqueue.c:2534
2534 ret = gst_pad_push_event (sq->sinkpad, event);
[Current thread is 1 (Thread 0x7f406c0258c0 (LWP 21925))]
(gdb) bt
0 0x00007f4062ec1399 in gst_multi_queue_src_event (pad=<optimized out>, parent=<optimized out>, event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gstreamer/plugins/elements/gstmultiqueue.c:2534
1 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_check (handler=0x7f4062ec1360 <gst_multi_queue_src_event>, event=0x7f3ff0007600 [GstEvent], parent=0x7f3fcc01f090 [GstMultiQueue|multiqueue167], pad_monitor=0x7f3fe809e7c0 [GstValidatePadMonitor|validatepadmonitor2213]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2101
2 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_func (pad=<optimized out>, parent=0x7f3fcc01f090 [GstMultiQueue|multiqueue167], event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2374
3 0x00007f406b904387 in gst_pad_send_event_unchecked (pad=pad@entry=0x7f3fdc027650 [GstPad|src_0], event=event@entry=0x7f3ff0007600 [GstEvent], type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5772
4 0x00007f406b90481b in gst_pad_push_event_unchecked (pad=pad@entry=0x7f4058182fc0 [GstPad|sink], event=event@entry=0x7f3ff0007600 [GstEvent], type=type@entry=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5417
5 0x00007f406b90f016 in gst_pad_push_event (pad=0x7f4058182fc0 [GstPad|sink], event=event@entry=0x7f3ff0007600 [GstEvent]) at ../subprojects/gstreamer/gst/gstpad.c:5554
6 0x00007f406a1c99ba in gst_video_decoder_src_event_default (decoder=0x7f3fe81c6060 [GstTheoraDec|theoradec46], event=<optimized out>) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1532
7 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_check (handler=0x7f406a1ca270 <gst_video_decoder_src_event>, event=0x7f3ff0007600 [GstEvent], parent=0x7f3fe81c6060 [GstTheoraDec|theoradec46], pad_monitor=0x7f4028163aa0 [GstValidatePadMonitor|validatepadmonitor2216]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2101
8 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_func (pad=<optimized out>, parent=0x7f3fe81c6060 [GstTheoraDec|theoradec46], event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2374
```
This make the GstSingleQueue a MiniObject, mainly so it is properly
refcounted.
This also make use of the GstMultiQueuePad class for srcpads which
is totally valid as srcpads and sinkpads share the same SingleQueue
object.
The `query` argument of gst_pad_query is "transfer none".
Query objects are "borrowed" by the pad query handlers and those
should never unref them.
This was leading to double freed queries in a very racy way with nested
GESTimelines.
By only having it on sinkpad-creation, it is racy to write a test
with a sometimes-pad (like a demuxer) that you want to pull from, having
the pull wait until the pad arrives and the buffer can be produced.
For the query function there's a risk that the function may be called
after the harness has been teared down. Since the function accesses a
pointer to the harness via the pad's data, the harness must protect
itself against this.
Event and chain function is also handled for constistency, although
they don't have the same problem since the gstpad.c checks whether the
pad is flushing before calling these.
This was a misguided effort to try and guarantee the buffers of
the sink pads would not change during aggregate, when an upstream
branch is seeked independently, however this is simply incorrect
as downstream has not necessarily been flushed, or the aggregate
function might be waiting to receive buffers on other pads.
In !159 , we switched to sending flush_start ourselves from the
do_seek implementation. If no flushing seek successfully made its
way upstream, we need to send flush_stop ourselves as well.
Releasing a GRecMutex from a different thread is undefined
behaviour.
There should be no reason to hold the stream lock from the
moment aggregator receives a flush_start until it receives
the last flush_stop: the source pad task is stopped, and can
only be restarted once the last flush_stop has arrived.
I can only speculate as to the reason why this was done,
as it was that way since the original commit. My best
guess is that aggregator originally didn't marshall events
and queries to the aggregate thread, and this somehow
helped work around this.
Instead of tracking "pending_flush_*" on the pads and the
aggregator, we now simply track the last seqnum for flush start
and flush stop events on the pads, and use it to determine whether
we should enter or exit our flushing state.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/977
Otherwise when seeking backwards we would keep the last_stop at the last
position we saw until playback passed the seek position again, and if
switching to the next pad happens in the meantime we would set the wrong
offset in the outgoing segment.
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means
we no longer need the macro there, but for most types in core we don't
want to break ABI, which means it's better to just keep it like it is
(and use the `#ifdef` instead).
This means we can use some newer features and get rid of some
boilerplate code using the `G_DECLARE_*` macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
