[Bug 750397] CRITICAL: Race condition in GstBus

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=750397

Matt Gruenke <mgruenke at tycoint.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #330467|needs-work                  |none
             status|                            |
 Attachment #330467|0                           |1
        is obsolete|                            |

--- Comment #55 from Matt Gruenke <mgruenke at tycoint.com> ---
Created attachment 330504
  --> https://bugzilla.gnome.org/attachment.cgi?id=330504&action=edit
Fix for Bug 750397 (Race condition in GstBus).

This addresses slightly different race conditions on Linux and Windows, and
fixes gst_poll_read_control() when control_pending == 0.

On Linux, the socketpair() used for control should not be made O_NONBLOCK.
If there's any propagation delay between set->control_write_fd.fd and
set->control_read_fd.fd, even the mutex now held will not be sufficient to
prevent a race condition.  There's no benefit to using O_NONBLOCK, here.
Only liabilities.

For Windows, it's necessary to fix the race condition between testing
set->control_pending and performing WAKE_EVENT()/RELEASE_EVENT().  This is
accomplished by acquiring and holding set->lock, for both of these operations.
We could optimize the Linux version by making this Windows-specific.

For consistency with the Linux implementation, Windows' RELEASE_EVENT()
has also been made to block, although it should never happen.

Also, changed release_wakeup() to return TRUE and decrement control_pending
only when > 0.  Furthermore, RELEASE_EVENT() is called only when
control_pending == 1.

Finally, changed control_pending to use normal, non-atomic arithmetic
operations, since it's now protected by set->lock.

Note: even though the underlying signaling mechanisms are blocking,
release_wakeup() is effectively non-blocking, as it will only attempt to read
from control_read_fd.fd after a byte has been written to control_write_fd.fd or
WaitForSingleObject() after it's been signaled.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.