decodebin2: fix pad leak and problem with GWeakRef code
authorTim-Philipp Müller <tim@centricular.com>
Sun, 24 Mar 2019 20:45:03 +0000 (20:45 +0000)
committerTim-Philipp Müller <tim@centricular.com>
Sun, 24 Mar 2019 21:55:43 +0000 (21:55 +0000)
commit4f73d3cf800359b4a30abd4b68e0a880397bd116
treef192069bbcbe6cd4be6c8b46a7bfe12fb743fe6a
parent3288093c75d0ff34e1a86cc0c5c0e71c036b83ee
decodebin2: fix pad leak and problem with GWeakRef code

Follow-up to !160 and commit 6a99ad2c.

Firstly, don't leak the sinkpad. g_weak_ref_get() returns
a strong reference (unless it returns NULL), so that must
be unrefed, as detected by the playbin-complex and
discoverer unit tests.

Next, if we do that we get invalid memory access when the
final pad ref is dropped a few lines below after the
request pad is released. The reason for this is that
GWeakRefs are not movable once they're in use, because
their address will be stored inside the object. In this
case the GWeakRef was embedded inside the GstDemuxerPad
struct which in turn was embedded inside the GArray data
section, and when the GArray gets resized, the structs
move. Just KISS and use a list with individual allocations
for each DemuxerPad instead.
gst/playback/gstdecodebin2.c