120 bytes in 5 blocks are definitely lost in loss record 7,615 of 9,510
at 0x484486F: malloc (vg_replace_malloc.c:380)
by 0x58A2938: g_malloc (gmem.c:106)
by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
by 0x588F059: g_list_prepend (glist.c:335)
by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
by 0x5B9CA8E: cleanup_cb (gstptpclock.c:1930)
by 0x589AD20: g_timeout_dispatch (gmain.c:4889)
by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
by 0x5899A92: g_main_loop_run (gmain.c:4329)
by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
by 0x58C8C31: g_thread_proxy (gthread.c:826)
576 bytes in 24 blocks are definitely lost in loss record 8,782 of 9,510
at 0x484486F: malloc (vg_replace_malloc.c:380)
by 0x58A2938: g_malloc (gmem.c:106)
by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
by 0x588F059: g_list_prepend (glist.c:335)
by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
by 0x5B9EFA0: handle_announce_message (gstptpclock.c:934)
by 0x5B9EFA0: handle_ptp_message (gstptpclock.c:1765)
by 0x5B9EFA0: have_stdin_data_cb (gstptpclock.c:1851)
by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
by 0x5899A92: g_main_loop_run (gmain.c:4329)
by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
by 0x58C8C31: g_thread_proxy (gthread.c:826)
by 0x5DA4298: start_thread (pthread_create.c:481)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/852>
When getting backtraces, we were always creating a new Dwfl context and then
discarding it. The problem with that is that it resulted in having to re-scan a
lot of information for every single backtrace.
In order to fix that issue, use a global on-demand Dwfl context and use it with
a lock.
Furthermore, we were scanning the mappings of the
process (dwfl_linux_proc_report) for *every single step* in the backtrace, and
that function is horrendously expensive (does sscanf on /proc/PID/maps
...). While there is a possibility that new mappings might be available (new
plugins being loaded for example), we can limit ourselves to just do it once per
backtrace.
These two modifications speed up the elements_leaks unit test (which traces all
pads with full backtraces) by a factor of 6.
Partially fixes#567
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/504>
Usually the latency message is only posted whenever latency of an
element changes but that might be too early as the sinks might not be
able to query the latency at that point yet.
Similarly adding a new sink should cause latency reconfiguration once
that new sink is able to report its latency.
This fixes latency configuration in pipelines where webrtcbin is the
only "sink", i.e. it is used in a sendonly session. Before, the latency
would always be configured to 0.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/843>
If a property is supplied to gst-launch-1.0 to set on a property that
implements GstChildProxy, it would always accept any property name
and try to set it later. This means that (for example) decodebin
will accept and not complain about property names that can never exist like:
gst-launch-1.0 videotestsrc ! decodebin NON-EXISTING_PROPERTY=adsfdasf ! fakesink
Instead, only try to do deferred property setting for property names
that contain the :: separator that indicates it's a setting on a child
that might appear later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/832>
This allows us to cover the case where we're on some unknown system that
doesn't have a known native precision monotonic time source. Sadly this
reintroduces some of the complexity removed in previous commits.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/829>
The gst_system_clock_get_internal_time and
gst_system_clock_get_resolution functions had some nested defined checks
making this code somewhat harder to reason about and much harder to
change. The logical meaning of the checks has changed but the actual
code coming out of the pre-processor should not have changed
significantly. The main logical change was flattening the checks for
existence of posix timing functionality, from what I can tell these
functions aren't available on Windows where they were trying to be
included. I have checked the Linux and macOS output and they are
functionally unchanged.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/829>
Most of these are only of historical interest, and for that it's
fine if they're maintained in the git history. They're confusing
for anyone stumbling across them expecting documentation relating
to current versions of GStreamer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/824>
Ensures that all unused threads are exited before the atexit()
handlers run.
This prevents a race with any thread that used the OpenSSL library
between it's thread cleanup routine and it's atexit() cleanup routine
which can cause a SIGSEGV.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/812>
The pads can be NULL when we're racing with pad removal, e.g. when the
pads get removed between `gst_pad_iterate_internal_links` acquiring the
parent element and `gst_multi_queue_iterate_internal_links` locking the
multiqueue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/810>
The name `gst_element_get_request_pad()` is confusing to people
learning GStreamer. `gst_element_request_pad_simple()` aims at
providing the exact same functionality, while making it more
explicit it is a simplified `gst_element_request_pad()`.
`gst_element_request_pad_simple()` is consistent with other
functions such as `gst_element_seek_simple`.
This commit deprecates `gst_element_get_request_pad()` so that a
compilation warning is emitted when used and incite developers
to use the more explicit `gst_element_request_pad_simple()`.
See also https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/743#note_886586
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/802>
Protect clearing probes against concurrent modification which might happen
due to dispose does NOT guarantee that the object is not used anymore, as
it could be referenced again and so being continued used.
So, as in the rest of places where probes hook list is used, on dispose
it should be accessed holding the mutex "GST_OBJECT_LOCK (pad);" as
GHookList is not thread-safe.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/798>
When posting buffering messages there are no safe places or timing to avoid
deadlocks.
Previously the code was trying to be "smart" by only forwarding serialized
queries if the queue was empty ... but that could happen when queue2 hadn't yet
posted a 100% buffering message. Meaning the pipeline might be paused and
pushing a serialized query downstream might never complete.
Therefore let's completely disable forwarding of serialized queries when
`queue2` is used as a buffering element (meaning `ALLOCATION` and `DRAIN`
queries).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/796>
The peeked buffer was always reset after calling ::aggregate() but under
no other circumstances. If a pad was removed after peeking and before
::aggregate() returned then the peeked buffer would be leaked.
This can easily happen if pads are removed from the aggregator from a
pad probe downstream of the source pad but still in the source pad's
streaming thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/784>
