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 768154 - d3dvideosink: start/stop concurrency between multiple sinks
d3dvideosink: start/stop concurrency between multiple sinks
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.8.2
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-28 20:22 UTC by Jonathan Roy
Modified: 2018-11-03 13:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0004-d3dvideosink-start-stop-lock.patch (2.05 KB, patch)
2016-06-28 20:22 UTC, Jonathan Roy
none Details | Review

Description Jonathan Roy 2016-06-28 20:22:55 UTC
Created attachment 330505 [details] [review]
0004-d3dvideosink-start-stop-lock.patch

Concurrent start/stop actions on multiple d3dvideosink instances running in parallel (distinct pipelines) may cause a crash. There is already a class mutex that is properly used in d3d_class_init and d3d_class_destroy, but it is momentarily released in both functions to let the window proc thread proceed. This opens up a breach for simultaneous start and/or stop calls to conflict, even on distinct sink instances.

Attached patch introduces another class mutex to serialize concurrent starts and stops.
Comment 1 Sebastian Dröge (slomo) 2016-06-28 21:40:12 UTC
Question is why the mutex is shortly released in both functions, and if you don't introduce the problem this was meant to prevent again by having another mutex around everything.
Comment 2 Jonathan Roy 2016-06-29 00:11:58 UTC
We need something to protect access to klass->d3d.thread, which klass->lock obviously cannot fulfil, because the thread in question (the window proc thread) itself locks klass->lock through d3d_class_ calls. That is why the lock has to be released momentarily when _start or _stop instantiate or terminate the thread (and intently waiting for that to happen).

As far as I can tell, the window proc thread never calls _start or _stop. Those methods are called on element state changes triggered outside of the element. Therefore, nothing will block on klass->start_stop_lock other than the _start and _stop calls, thereby achieving the serialization effect we are looking for.

We stumbled on this issue through robustness testing (start/stop cycles every few seconds running for several hours). Doesn't occur that often, and it is quite possible it would never happen while running only a single sink at a time.
Comment 3 GStreamer system administrator 2018-11-03 13:52:45 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/404.