[Bug 742684] aggregator: Usage of GCond is racy.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=742684
  GStreamer | gst-plugins-bad | git

Thibault Saunier <tsaunier> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tsaunier at gnome.org

--- Comment #2 from Thibault Saunier <tsaunier at gnome.org> 2015-01-10 07:54:15 UTC ---
We have run those test for nights and have been very careful in the management
of those locking issue so this is for sure a regression in recent code. Where
in the code did you detect those issues?

Putting that bug as blocker.

(In reply to comment #1)
> Actually, all of the locking around flushing and seeking is quite dodgy. There
> are a bunch of probably useless atomics, where the same variable is read
> somewhere else without the atomics. The stream lock is taken in the flush_start
> and released on a flush_stop.. But after a flush start, there is no guarantee
> you'll get a flush_stop, you could get a state change to NULL instead!

This is the case only after a flushing seek... Please give more detailed
comments because that "it looks wrong" without any detail is not that useful.


> I'm not  sure I understand why the duplicated
> gst_aggregator_pad_steal_buffer() in flush_start ?

To handle the case were we had a queued buffer and a thread blocked in _chain
waiting for the first buffer to be unqueued.

> To make it fail:
> 
> GST_CHECKS=test_flush_start_flush_stop make elements/audiomixer.forever
> GST_CHECKS=test_live_seeking make elements/audiomixer.forever

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.