Previously we would use the object lock only for storing the sync
handler and its user_data in a local variable, then unlock it and only
then call the sync handler. Between unlocking and calling the sync
handler it might be unset and the user_data be freed, causing it to be
called with a freed pointer.
To prevent this add a refcounting wrapper struct around the sync
handler, hold the object lock while retrieving it and increasing the
reference count and only actually free it once the reference count
reaches zero.
As a side-effect we can now also allow to actually replace the sync
handler. Previously it was only allowed to clear it after initially
setting it according to the docs, but the code still allowed to clear it
and then set a different one.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/506
After release bison 2.5 the declaration %pure-parser was deprecated
in favor of %define api.pure
Nonetheless, until bison 3.4, the declaration was treated as backward
compatibility, but now bison shows a warning:
warning: deprecated directive, use ‘%define api.pure’
The patch's approach is to handle both directives according with the
used bison's version, by string replacement at source configuration
stage.
This reverts a96002bb28, which is not
necessary anymore. If we release the pad after removing it then none of
the deactivation code will actually be called because the pad has no
parent anymore, and we require a parent on the pad for deactivation to
happen.
This can then, among other things, cause a streaming thread to be still
stuck in a pad probe because the pad was never flushed, and waiting
there forever because now the pad will actually never be flushed anymore.
If a pad is currently being released we don't want to forward the
FLUSHING flow return but instead consider it as NOT_LINKED. FLUSHING
would also cause upstream to be FLUSHING.
This part was missed in a3c4a3201a and
resulted in a different (and wrong) workaround in
a96002bb28.
Otherwise we're not guaranteed to read the very latest value that
another thread might've written in there when the pad was released, and
could instead work with an old value.
The argument must be at least a GObject according to the GstLogFunction
definition, and while the default C log function handles miniobjects
just fine this is crashing bindings and user-supplied log functions that
(rightfully) don't expect anything but GObjects.
Concurrent Windows' colored debug message and g_print will print
string hard to read. Instead, use gst_print* which serialize
debug output and the APIs call.
On Windows, concurrent colored gstreamr debug output and usual
stdout/stderr string will cause broken output on terminal.
Since it's OS specific behavior, that's hard to completely avoid it
but we can protect it at least among our printing interfaces side.
In cases with many long-lived buffers that have qdata only very
briefly, the memory overhead of keeping an array of 16 GstQData
structs for each buffer can be significant. We free the array when
the last qdata is removed, like it was done in 1.14.
Fixes#436
This patch simply add a null check around a case where a child may have
been unparented concurrently to the deep_add_remove operation. This was
found by accident in the form of an "IS_GST_OBJECT" assertion, but had
no other known side effect in that test.
The install kwarg on configure_file() was only added in
Meson 0.50 but we're targetting older versions as well,
which caused a warning. The install kwarg is not needed
here as we specify install_dir, so we can just drop it.
Fixes#379
The documentation says that this allows the subclass to signal that it
needs more data before it can decide on caps, so let's actually
implement it that way.
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.
In gst_download_buffer_wait_for_data(), when a seek is made with
perform_seek_to_offset() the `qlock` is released temporarily. Therefore,
the flushing condition can be set during this period and should be
checked.
This was not being checked before, causing occasional deadlocks when
GST_DOWNLOAD_BUFFER_WAIT_ADD_CHECK() was called.
GST_DOWNLOAD_BUFFER_WAIT_ADD_CHECK() assumes that the caller has already
checked that we're not flushing before, since this is done when
acquiring the lock; so if we release it temporarily somewhere, we need
to check for flush again.
Without that check, the function would keep waiting for the condition
variable to be notified before checking for flushing condition again,
and that may very well never happen. This was reproduced when during pad
deactivation when running WebKit in gdb.
This was added in 1.16 and accidentally duplicated the value of
the existing GST_MESSAGE_REDIRECT.
As the only known user of this message is GStreamer core itself,
and it is quite an obscure message, it seems best to just fix up
the enum value even if that technically breaks API.
Fixes#418
gst_ring_buffer_logger_log calls several functions while formatting
the message which may in turn log a message while we already hold
the mutex. Do all formatting first before acquiring the mutex to
avoid this and reduce the time we hold the mutex.
sync=TRUE implementation changes the latency query of a non-live
upstream into live, though it wrongly set the upstream max latency to 0.
As non-live sources won't loose data if we wait longer, this should have
been reported as have no max latency limite (-1).
When passing "sink_%d" twice to aggregator before it would create two
pads called "sink_0", because it failed to parse "%d" as integer and
used 0 instead then.
Instead validate that parsing was actually successful and also don't
even try to parse if the requested pad name contains a '%'.
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
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.
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.
Not that it matters, since we don't check the return value
anyway. Unclear why the aggregator pad flush function should
have a return value at all really, and perhaps it should be
called reset anyway. Spotted by dv on irc.
Before GST_PAD_PROBE_HANDLED was introduced, we had to handle the case
where some probes would reset the probe info data field to NULL. This would
be considered an invalid use-case.
But with GST_PAD_PROBE_HANDLED it is totally fine to reset that, since
the probe has "handled" it.
