[Bug 742684] aggregator: Usage of GCond is racy.
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Fri Jan 9 23:54:17 PST 2015
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.
More information about the gstreamer-bugs
mailing list