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 708661 - elements/multiqueue test_output_order racy
elements/multiqueue test_output_order racy
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-24 06:34 UTC by Edward Hervey
Modified: 2018-01-15 10:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2013-09-24 06:34:33 UTC
the test_output_order "check" is racy.

 (CK_FORK=no GST_CHECK=test_output_order make elements/multiqueue.forever).

The problem is indeed the test and not the actual element behaviour.

The objects to push are being pulled out of the single internal queues in the right order and at the right time...

But between:
* the moment the global multiqueue lock is released (which was used to detect if we should pop and push downstream the next buffer)
* and the moment it is received by the source pad (which does the check)

=> another single queue (like the unlinked pad) might pop and push a buffer downstream

What should we do ? Putting a bigger margin of error (say 5 buffers) doesn't help, it'll eventually fail.

I can't see how we can detect this reliably.
Comment 1 Edward Hervey 2018-01-15 10:43:08 UTC
Closing. Haven't seen it in ages.