Always hold a reference to the soft volume element
provided by the playsinkaudioconvert bin helper, the
same as when volume is provided by a sink element,
or the soft volume element gets unreffed too soon.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3113>
It would constantly want to renegotiate (and spam the debug log) even
though the channel layout hasn't actually changed. We use the same
fallback in gst_ffmpegauddec_negotiate() already.
This happens with WMA files for example.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3105>
We need to call this to register the MusixBrainz tags before we use
them in an XMP schema.
Fixes this critical when attempting to run jpegparse on a JPEG
containing MusicBrainz XMP tags:
GStreamer-CRITICAL **: 20:41:07.885: gst_tag_get_type: assertion 'info != NULL' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3095>
The purpose of a deep buffer copy is to be able to release the source
buffer and all its dependencies. Attaching the parent buffer meta to
the newly created deep copy needlessly keeps holding a reference to the
parent buffer.
The issue this solves is the fact you need to allocate more
buffers, as you have free buffers being held for no reason. In the good
cases it will use more memory, in the bad case it will stall your
pipeline (since codecs often need a minimum number of buffers to
actually work).
Fixes#283
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3090>
Since commit a79a756b79 we could change to ignore-pcr automatically at 500ms
into a live stream when no PCR is seen by then. However the stream counting in
program change detection was wrongly considering ignore-pcr programs to have a
separate PCR PID, even though we are actually ignoring the PCR PID completely,
resulting in an erroneous program switch getting triggered from the different
stream count. This in turn would send an EOS and switch out the pads for what
actually is still the same program, while we intended to simply apply a
workaround for broken encoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3089>
Check that `self` and `self->callback` are defined. `self` can be set to
`NULL` in `remove_listener`, and `self->callback` can be set to `NULL`
inside `gst_amc_surface_texture_jni_set_on_frame_available_callback`.
This can cause a segfault since the Java object can outlive the C
object, and call the callback after `remove_listener` is called.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3056>
Check back pressure of a stream transport before popping buffer from its backlog.
If the stream transport is not experiencing back pressure, the buffer can be popped from backlog and pushed to client.
Fixes:#1298
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2998>
Timers for RTX packets are dealt with later in update_rtx_timers(), and
timers for non-RTX packets would potentially also be unscheduled a
second time from there so avoid that.
Also don't shadow the timer variable from the outer scope but instead
make use of it directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2996>
The address/port is pre-defined by the caller of the function, so
retrying is only going to loop forever.
Ideally the multicast address should be checked after allocating but
this doesn't happen currently, so it's better to error out cleanly then
to loop forever trying the same address.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2997>
If read_one or write_one was called but the stream closed before it could
read/write a whole packet, read_one/write_one would hang indefinitely,
consuming 100% CPU. This commit fixes that by treating a short read/write
as an error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2994>
Current default G_MAXINT is not a correct value under any circumstances.
This creates an issue with screen capture, during which we currently do
not get any framerate info causing G_MAXINT to show up, where elements
downstream can possibly misbehave - for example, `vtenc` causes
a kernel panic.
Replace with 30/1 to avoid such scenarios.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2946>
Remove pcre.wrap since it is pulled in automatically by glib and not
used by gstreamer.
Hopefully this fixes the msvc ci on the 1.20 branch which failed with
"gregex.c.obj : error LNK2001: unresolved external symbol pcre_free"
on pcre-8.45.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2985>
Nouveau driver currently only exposes postproc entry. But
vaapidecodebin is registered independent if there are decoders or not,
exposing a segmentation fault.
This patch removes the encoder/decoder/codec arrays if no entries are
found, and if no decoders are found vaapidecodebin is not
registered. Also for vaapipostproc if no postproc entry is found.
Also, if general decoder, used by vaapidecodebin, doesn't have a sink
pad string, don't register the glib type.
Fixes: #1349
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2906>
Without this change cleanup function for g_autoptr is not defined for
GstPlayMediaInfo, GstPlaySignalAdapter, GstPlayVideoRenderer,
GstPlayVideoOverlayVideoRenderer and GstPlayVisualization. Cleanup
function was defined in gstplay.h, but missing in other header files.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2904>
When stopping the element, make sure the pad task
is stopped before destroying the part readers.
Closes a race where the pad task might access
a freed pointer.
Also add a guard against this sort of thing
by holding a ref to the reader in the pad loop.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2902>
The parent refcount is of the *transformed* buffer, not the input
buffer.
Also update the docs to clarify that @transbuf is the transformed
buffer, and not the buffer on which a transformation is being
performed.
Due to this bug, modifying the structure of a meta that has been
copied to another buffer fails with:
gst_structure_set: assertion 'IS_MUTABLE (structure) || field == NULL' failed
Add a test for the same.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2894>
Newer compilers ( clang 15 ) have turned stricter and errors out instead
of warning on implicit function declations
Fixes
gstssaparse.c:297:12: error: call to undeclared library function 'isspace' with type 'int (int)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
while (isspace(*t))
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2882>
Ideally new() functions should simply call g_object_new() and not much
else, so let's do that here and handle all the construction properly in
a GObject way.
Now a play object created via g_object_new() is actually usable.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2881>
Ideally new() functions should simply call g_object_new() and not much
else, so let's do that here and handle all the construction properly in
a GObject way.
Now a player object created via g_object_new() is actually usable.
In addition, also fix the video-renderer property so that reading it
returns an object of the correct type.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2881>
That is, get rid of unnecessary and wrong special-casing.
This could always use gst_rtsp_url_get_request_uri_with_control() but as
we only have the control base URI as string it is easier to just call
gst_uri_join_strings().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2877>
This was showing up as a memory leak in GTK's
gstreamer media backend:
40 bytes in 1 blocks are definitely lost in loss record 18,487 of 40,868
at 0x484586F: malloc (vg_replace_malloc.c:381)
by 0x50D5278: g_malloc (gmem.c:125)
by 0x50EDBA5: g_slice_alloc (gslice.c:1072)
by 0x50EFBCC: g_slice_alloc0 (gslice.c:1098)
by 0x51F2F45: g_type_create_instance (gtype.c:1911)
by 0x51DAE37: g_object_new_internal (gobject.c:2011)
by 0x51DC080: g_object_new_with_properties (gobject.c:2181)
by 0x51DCB20: g_object_new (gobject.c:1821)
by 0x9855F86: UnknownInlinedFun (gstplayer-wrapped-video-renderer.c:109)
by 0x9855F86: gst_player_new (gstplayer.c:579)
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1374
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2876>
Otherwise we won't send the protection packets for the last few
packets when a stream ends.
Also send EOS on the FEC src row pad immediately, and on the FEC src
column pad after draining is complete. This makes it so that the FEC
src pads on rtpbin behave the same way as the RTCP src pads on rtpbin
when EOS is received on the send_rtp_sink pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2874>
When a new segment event arrives, it immediately updates
the current stored segment, which was used for calculating
the running time of the current text buffer for every
passing video frame. This means a segment that arrives
after the text buffer might get used to (mis)calculate
the running times subsequently.
Instead, calculate and store the right running time
using the current segment when storing the buffer. Later
the stored segment can get freely updated.
This fixes the case where pieces of video and text streams
are seamlessly concatenated and fed through the text overlay.
Previously, it could lead to the current text buffer suddenly
have a massive running time and blocking all further input.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2872>
The is_gst_mini_object_check would sometimes detect a proper GObject
as a mini object, and then bad things happen.
We know whether a pointer is a proper GObject or a MiniObject here
though, so just pass that information to the right code paths and
avoid the heuristics altogether.
Eliminates all remaining uses of object_is_gst_mini_object().
Fixes#1334
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2846>
The is_gst_mini_object_check would sometimes detect a proper GObject
as a mini object, and then bad things happen.
We know whether a pointer is a proper GObject or a MiniObject here
though, so just pass that information to the right code paths and
avoid the heuristics altogether.
There are probably more cases where the check should be eliminated.
Fixes#1334, maybe
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2846>
With the 2.72 release, glib-networking developers have decided that
TLS certificate validation cannot be implemented correctly by them, so
they've deprecated it.
In a nutshell: a cert can have several validation errors, but there
are no guarantees that the TLS backend will return all those errors,
and things are made even more complicated by the fact that the list of
errors might refer to certs that are added for backwards-compat and
won't actually be used by the TLS library.
Our best option is to ignore the deprecation and pass the warning onto
users so they can make an appropriate security decision regarding
this.
We can't deprecate the tls-validation-flags property because it is
very useful when connecting to RTSP cameras that will never get
updates to fix certificate errors.
Relevant upstream merge requests / issues:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2214https://gitlab.gnome.org/GNOME/glib-networking/-/issues/179https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/193
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2818>
Forgot to change the wrap type in e0014ef4fe which broke the
subproject. Wasn't noticed by CI because the subproject cache wasn't
regenerated.
The accompanied patch was included in 2.8.2, so it is not needed. It
was originally needed with 2.8.1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2808>
It is entirely possible for the cancellable to be cancelled (and freed)
in gst_rtsp_connection_flush() while there may be an ongoing read/write
operation.
Nothing prevents gst_rtsp_connection_flush() from waiting for the
outstanding read/writes.
This could lead to a crash like (where cancellable has been freed
within gst_rtsp_connection_flush()):
#0 0x00007ffff4351096 in g_output_stream_writev (stream=stream@entry=0x7fff30002950, vectors=vectors@entry=0x7ffe2c6afa80, n_vectors=n_vectors@entry=3, bytes_written=bytes_written@entry=0x7ffe2c6af950, cancellable=cancellable@entry=0x7fff300288a0, error=error@entry=0x7ffe2c6af958) at ../subprojects/glib/gio/goutputstream.c:377
#1 0x00007ffff44b2c38 in writev_bytes (stream=0x7fff30002950, vectors=vectors@entry=0x7ffe2c6afa80, n_vectors=n_vectors@entry=3, bytes_written=bytes_written@entry=0x7ffe2c6afb90, block=block@entry=1, cancellable=0x7fff300288a0) at ../subprojects/gst-plugins-base/gst-libs/gst/rtsp/gstrtspconnection.c:1320
#2 0x00007ffff44b583e in gst_rtsp_connection_send_messages_usec (conn=0x7fff30001370, messages=messages@entry=0x7ffe2c6afcc0, n_messages=n_messages@entry=1, timeout=timeout@entry=3000000) at ../subprojects/gst-plugins-base/gst-libs/gst/rtsp/gstrtspconnection.c:2056
#3 0x00007ffff44d2669 in gst_rtsp_client_sink_connection_send_messages (sink=0x7fffac0192c0, timeout=3000000, n_messages=1, messages=0x7ffe2c6afcc0, conninfo=0x7fffac019610) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:1929
#4 gst_rtsp_client_sink_try_send (sink=sink@entry=0x7fffac0192c0, conninfo=conninfo@entry=0x7fffac019610, requests=requests@entry=0x7ffe2c6afcc0, n_requests=n_requests@entry=1, response=response@entry=0x0, code=code@entry=0x0) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:2845
#5 0x00007ffff44d3077 in do_send_data (buffer=0x7fff38075c60, channel=<optimized out>, context=0x7fffac042640) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:3896
#6 0x00007ffff4281cc6 in gst_rtsp_stream_transport_send_rtp (trans=trans@entry=0x7fff20061f80, buffer=<optimized out>) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream-transport.c:632
#7 0x00007ffff4278e9b in push_data (stream=0x7fff40019bf0, is_rtp=<optimized out>, buffer_list=0x0, buffer=<optimized out>, trans=0x7fff20061f80) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2586
#8 check_transport_backlog (stream=0x7fff40019bf0, trans=0x7fff20061f80) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2645
#9 0x00007ffff42793b3 in send_tcp_message (idx=<optimized out>, stream=0x7fff40019bf0) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2741
#10 send_func (stream=0x7fff40019bf0) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2776
#11 0x00007ffff7d59fad in g_thread_proxy (data=0x7fffbc062920) at ../subprojects/glib/glib/gthread.c:827
#12 0x00007ffff7a8ce2d in start_thread () from /lib64/libc.so.6
#13 0x00007ffff7b12620 in clone3 () from /lib64/libc.so.6
Fix by adding a cancellable lock and returning an extra reference used
across all read/write operations. gst_rtsp_connection_flush() can free
the in-use cancellable and it will no longer affect any in progress
read/write.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2816>
The caps negotiation should respect the selected method to the test pipeline below works properly.
gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=600 ! videoflip method=clockwise ! video/x-raw,width=600,height=320 ! fakesink
Signed-off-by: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2815>
In the trick mode, driver may queue a valid buffer follow by an
empty buffer which has no valid data to indicate EOS.For the empty
buffer whose memory is multi-plane, need to resize it before
unreference it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2794>
4x downscaling of chroma with co-sited chroma has never worked
it seems.
Fixes incorrect videotestsrc output and videoconvert conversions
to Y41B, YUV9, YVU9 and IYU9 with co-sited chroma.
e.g.
gst-launch-1.0 videotestsrc ! video/x-raw,format=Y41B,width=1280,height=720 ! \
videoconvert ! autovideosink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2791>
There might be a sequence of event and buffer flow:
- Got stream-start/caps/segment events
- Got flush events
- And then buffers with a new segment event
In the above case, stream-start and caps event might not be reached to
peer proxysrc if peer proxysrc is not ready to receive them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2774>
And also don't assert that there are no buffers queued up when handling
an EOS event. The pad's streaming thread might've already received a new
stream-start event and queued up a buffer in the meantime.
This still leaves a race condition where the srcpad task sees all pads
in EOS state and finishes the stream, while shortly afterwards a pad
might receive a stream-start event again, but this doesn't seem to be
solveable with the current aggregator design.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2772>
In file included from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:87,
from ../gst-plugins-good-1.20.3/ext/qt/qtglrenderer.cc:14:
../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/gstreamer-1.0/gst/gl/glprototypes/gstgl_compat.h:40:18: error: conflicting declaration 'typedef void* GLsync'
40 | typedef gpointer GLsync;
| ^~~~~~
In file included from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtGui/qopengl.h:127,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsggeometry.h:44,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsgnode.h:43,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsgrendererinterface.h:43,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qquickwindow.h:44,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/QQuickWindow:1,
from ../gst-plugins-good-1.20.3/ext/qt/qtglrenderer.cc:6:
../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtGui/qopengles2ext.h:24:26: note: previous declaration as 'typedef struct __GLsync* GLsync'
24 | typedef struct __GLsync *GLsync;
| ^~~~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2771>
These patches are taken from upstream, and they fix compile failures
with latest clang. These can be dropped when upgrading these wraps.
This is currently causing a warning because we do not require the
version of meson that ships with this feature: 0.63.0. The version has
not been bumped because older Meson versions gracefully ignore the
wrap field, this fix is optional and only needed on macOS, and 0.63.0
is a very new release with a bug that partially breaks this feature:
https://github.com/mesonbuild/meson/pull/10602
We can consider bumping the requirement once 0.63.1 is released.
Also switch from git to tarballs, no reason to use git here anymore.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2764>
The AVClass name of Animated PNG in FFmpeg 5.x is "(A)PNG"
and it will be converted to "-a-png" through
g_ascii_strdown() and g_strcanon(). But GLib disallow leading '-'
character for a GType name. Strip leading '-' to workaround it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2733>
- ssl module requires an explicit TLS_SERVER role
- asyncio throws a deprecation warning when using
asyncio.get_event_loop(). Remove custom event loop handling entirely
- No need to keep the websocket server in a member variable, can use
a future to signal exit case along with the async with context manager
of websockets.serve()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2711>
If compiled with -Dgstreamer:gst_debug=false and we have
GST_REMOVE_DISABLED defined we will get the following compiler error:
```
[...]/libgstreamer-1.0.so.0.2100.0.p/gst.c.o: in function `gst_deinit':
[...]/gst/gst.c:1258: undefined reference to `_priv_gst_debug_cleanup'
[...] hidden symbol `_priv_gst_debug_cleanup' isn't defined
```
Add the missing define guard to avoid this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2649>
Gallium drivers historically have reported strange dmabuf sizes, from always
zero to the whole frame (multiple fds). The simplest solution is to use lseek
SEEK_END to get the prime descriptor size.
Also the allocator raises a warning if both values differ in order to report
it to driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2657>
Some problematic H265 stream may miss the reference frame in the DPB,
and get some message like: "No short term reference picture for xxx".
So there may be empty entries in ref_pic_list0/1 when passing to
decode_slice() function of sub class. We need to check the NULL pointer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2647>
Previously it was only possible to request them with the exact template
name, e.g. 'src_%s', but not with "instantiated" names that would match
this template, e.g.'src_foo_bar'.
This is now possible and a test was added for this, in addition to
fixing a previously invalid test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2645>
This allows the reception of streams that don't exactly match
the codec preferences. In particular, the ssrc in the codec preferences
is local sender SSRC, the other side is expected to send a different SSRC.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2632>
Various variables were of smaller types than needed and there were no
checks for any overflows when doing additions on the sizes. This is all
checked now.
In addition the size of the decompressed data is limited to 200MB now as
any larger sizes are likely pathological and we can avoid out of memory
situations in many cases like this.
Also fix a bug where the available output size on the next iteration in
the zlib decompression code was provided too large and could
potentially lead to out of bound writes.
Thanks to Adam Doupe for analyzing and reporting the issue.
CVE: tbd
https://gstreamer.freedesktop.org/security/sa-2022-0003.html
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2611>
Various variables were of smaller types than needed and there were no
checks for any overflows when doing additions on the sizes. This is all
checked now.
In addition the size of the decompressed data is limited to 120MB now as
any larger sizes are likely pathological and we can avoid out of memory
situations in many cases like this.
Also fix a bug where the available output size on the next iteration in
the zlib/bz2 decompression code was provided too large and could
potentially lead to out of bound writes.
Thanks to Adam Doupe for analyzing and reporting the issue.
CVE: CVE-2022-1922, CVE-2022-1923, CVE-2022-1924, CVE-2022-1925
https://gstreamer.freedesktop.org/security/sa-2022-0002.html
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2611>
The mq we get out of the weak ref might be NULL if we're
shutting down, which could cause assertion failures or
crashes.
It might also cause miscompilations where the compiler just
optimises away the NULL check because it jumps to a code path
that then dereferences the pointer which clearly isn't going
to work. Seems like something like this happens with gcc 11.
Fixes#1262
Co-authored-by: Doug Nazar <nazard@nazar.ca>
Co-authored-by: Sebastian Dröge <sebastian@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2600>
Fixes:
../plugins/elements/gstmultiqueue.c: In function ‘gst_multi_queue_loop’:
../plugins/elements/gstmultiqueue.c:2394:19: warning: ‘is_query’ may be used uninitialized in this function [-Wmaybe-uninitialized]
2394 | if (object && !is_query)
| ^~~~~~~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2596>
gtk_gl_area_get_error() doesn't return a copy of the error, but just the
error. If initialising OpenGL fails, then GtkGstGLWidget will consume
the error, and cause GTK to try and display freed memory.
==50914== Invalid read of size 8
==50914== at 0x4C4CB8A: gtk_gl_area_draw_error_screen (gtkglarea.c:663)
==50914== by 0x4C4CB8A: gtk_gl_area_draw (gtkglarea.c:687)
==50914== by 0x4E061CA: gtk_widget_draw_internal (gtkwidget.c:7084)
==50914== by 0x4BAEFB1: gtk_container_propagate_draw (gtkcontainer.c:3854)
==50914== by 0x4D4B6BF: gtk_stack_render (gtkstack.c:2207)
==50914== by 0x4BB4B03: gtk_css_custom_gadget_draw (gtkcsscustomgadget.c:159)
==50914== by 0x4BBA4C4: gtk_css_gadget_draw (gtkcssgadget.c:885)
==50914== by 0x4D4D780: gtk_stack_draw (gtkstack.c:2119)
==50914== by 0x4E061CA: gtk_widget_draw_internal (gtkwidget.c:7084)
==50914== by 0x4BAEFB1: gtk_container_propagate_draw (gtkcontainer.c:3854)
==50914== by 0x4BAF0C3: gtk_container_draw (gtkcontainer.c:3674)
==50914== by 0x4E061CA: gtk_widget_draw_internal (gtkwidget.c:7084)
==50914== by 0x4BAEFB1: gtk_container_propagate_draw (gtkcontainer.c:3854)
==50914== Address 0x187a0818 is 8 bytes inside a block of size 16 free'd
==50914== at 0x48480E4: free (vg_replace_malloc.c:872)
==50914== by 0x49A5B8C: g_free (gmem.c:218)
==50914== by 0x49C1013: g_slice_free1 (gslice.c:1183)
==50914== by 0x4990DE4: g_error_free (gerror.c:870)
==50914== by 0x4990FE9: g_clear_error (gerror.c:1052)
==50914== by 0x1A489780: _get_gl_context (gtkgstglwidget.c:540)
==50914== by 0x1A4863CB: gst_gtk_invoke_func (gstgtkutils.c:39)
==50914== by 0x49A3834: g_main_context_invoke_full (gmain.c:6137)
==50914== by 0x1A486450: gst_gtk_invoke_on_main (gstgtkutils.c:59)
==50914== by 0x1A48A29E: gtk_gst_gl_widget_init_winsys (gtkgstglwidget.c:632)
==50914== by 0x1A4887E7: gst_gtk_gl_sink_start (gstgtkglsink.c:267)
==50914== by 0x6579810: gst_base_sink_change_state (gstbasesink.c:5662)
==50914== Block was alloc'd at
==50914== at 0x484586F: malloc (vg_replace_malloc.c:381)
==50914== by 0x49A9278: g_malloc (gmem.c:125)
==50914== by 0x49C1BA5: g_slice_alloc (gslice.c:1072)
==50914== by 0x49C3BCC: g_slice_alloc0 (gslice.c:1098)
==50914== by 0x499096B: g_error_allocate (gerror.c:708)
==50914== by 0x4990AF1: UnknownInlinedFun (gerror.c:722)
==50914== by 0x4990AF1: g_error_copy (gerror.c:892)
==50914== by 0x4C4B9F9: gtk_gl_area_set_error (gtkglarea.c:1036)
==50914== by 0x4C4BAF7: gtk_gl_area_real_create_context (gtkglarea.c:346)
==50914== by 0x4B21B28: _gtk_marshal_OBJECT__VOIDv (gtkmarshalers.c:2730)
==50914== by 0x4920B78: UnknownInlinedFun (gclosure.c:893)
==50914== by 0x4920B78: g_signal_emit_valist (gsignal.c:3406)
==50914== by 0x4920CB2: g_signal_emit (gsignal.c:3553)
==50914== by 0x4C4B927: gtk_gl_area_realize (gtkglarea.c:308)
Reproduced by running:
MESA_GL_VERSION_OVERRIDE=2.7 totem
See https://gitlab.gnome.org/GNOME/totem/-/issues/522
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2567>
