Commit 31914404 authored by Tim-Philipp Müller's avatar Tim-Philipp Müller 🐠

tee: fix use of possibly-freed pad in debug statement

The gst_object_unref() in the block above may be dropping
the last ref to the pad and free the pad. Set pad pointer
to NULL here, so that we don't accidentally use a
possibly-freed pad pointer in the debug log statements
further below, and also use the tee element as log object
since that's more appropriate anyway.

Fixes valgrind warnings and crashes in tee test_stress
unit test when debug logging is enabled.
parent 7fa81b53
......@@ -703,6 +703,7 @@ restart:
GST_TEE_PAD_CAST (pad)->pushed = TRUE;
GST_TEE_PAD_CAST (pad)->result = ret;
gst_object_unref (pad);
pad = NULL;
} else {
/* already pushed, use previous return value */
ret = GST_TEE_PAD_CAST (pad)->result;
......@@ -714,7 +715,7 @@ restart:
* the same. It could be possible that the pad we just pushed was removed
* and the return value it not valid anymore */
if (G_UNLIKELY (GST_ELEMENT_CAST (tee)->pads_cookie != cookie)) {
GST_LOG_OBJECT (pad, "pad list changed");
GST_LOG_OBJECT (tee, "pad list changed");
/* the list of pads changed, restart iteration. Pads that we already
* pushed on and are still in the new list, will not be pushed on
* again. */
......@@ -727,7 +728,7 @@ restart:
/* keep all other return values, overwriting the previous one. */
GST_LOG_OBJECT (pad, "Replacing ret val %d with %d", cret, ret);
GST_LOG_OBJECT (tee, "Replacing ret val %d with %d", cret, ret);
cret = ret;
pads = g_list_next (pads);
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment