After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795987 - pad: Race condition with probe cookies causing the same probe to be called multiple times
pad: Race condition with probe cookies causing the same probe to be called mu...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal critical
: 1.15.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-05-09 21:20 UTC by Sebastian Dröge (slomo)
Modified: 2018-05-11 15:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
WIP: pad: Fix race condition causing the same probe to be called multiple times (6.03 KB, patch)
2018-05-09 21:20 UTC, Sebastian Dröge (slomo)
none Details | Review
pad: Fix race condition causing the same probe to be called multiple times (7.33 KB, patch)
2018-05-10 08:23 UTC, Sebastian Dröge (slomo)
none Details | Review
pad: Fix race condition causing the same probe to be called multiple times (7.64 KB, patch)
2018-05-11 15:53 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2018-05-09 21:20:26 UTC
See attached patch and commit message.
Comment 1 Sebastian Dröge (slomo) 2018-05-09 21:20:33 UTC
Created attachment 371870 [details] [review]
WIP: pad: Fix race condition causing the same probe to be called multiple times

Probes were remembering a cookie that was used to check if the probe was
already called this time before the probes list changed. However the
same probes could've been called by another thread in between and thus
gotten a new cookie, and would then be called a second time.

FIXME: We remember all called probes in a GSList for now, causing lots
of new allocations. An allocation-free solution should be found.
Comment 2 Tim-Philipp Müller 2018-05-09 22:15:06 UTC
Maybe we can do something with an g_alloca()-ed array? Keep track how much space we allocated, and if we exceed it just do a new g_alloca() copy old array over and continue. There's surely a limit to the number of probes on a pad in practice?
Comment 3 Sebastian Dröge (slomo) 2018-05-10 07:13:53 UTC
(In reply to Tim-Philipp Müller from comment #2)
> Maybe we can do something with an g_alloca()-ed array? Keep track how much
> space we allocated, and if we exceed it just do a new g_alloca() copy old
> array over and continue. There's surely a limit to the number of probes on a
> pad in practice?

Yes except that if you use g_alloca() inside a loop, the allocation will be gone every iteration (we have a "goto again" loop here).

I could allocate a big enough array with g_alloca (16 items is surely enough?), and if that ever happens to be not enough re-allocate with g_malloc
Comment 4 Sebastian Dröge (slomo) 2018-05-10 08:23:01 UTC
Created attachment 371881 [details] [review]
pad: Fix race condition causing the same probe to be called multiple times

Probes were remembering a cookie that was used to check if the probe was
already called this time before the probes list changed. However the
same probes could've been called by another thread in between and thus
gotten a new cookie, and would then be called a second time.
Comment 5 Sebastian Dröge (slomo) 2018-05-10 08:43:41 UTC
Review of attachment 371881 [details] [review]:

::: gst/gstpad.c
@@ +3475,2 @@
   /* if we have called this callback, do nothing */
+  for (i = 0; i < data->n_called_probes; i++) {

This loop is quadratic in number of probes... but this shouldn't really matter in practice.

@@ +3487,3 @@
+      data->called_probes_size *= 2;
+      data->called_probes =
+          g_renew (GHook *, data->called_probes, data->called_probes_size);

realloc here because it's potentially more efficient than the code path below with memcpy
Comment 6 Sebastian Dröge (slomo) 2018-05-11 15:53:50 UTC
Created attachment 371941 [details] [review]
pad: Fix race condition causing the same probe to be called multiple times

Probes were remembering a cookie that was used to check if the probe was
already called this time before the probes list changed. However the
same probes could've been called by another thread in between and thus
gotten a new cookie, and would then be called a second time.
Comment 7 Sebastian Dröge (slomo) 2018-05-11 15:55:35 UTC
Attachment 371941 [details] pushed as 13d5957 - pad: Fix race condition causing the same probe to be called multiple times