mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-20 00:31:13 +00:00
Code Issues 1 Projects Releases Wiki Activity

check: Disable multiqueue test_output_order check

Browse source 
The check itself 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.

https://bugzilla.gnome.org/show_bug.cgi?id=708661
This commit is contained in:
Edward Hervey 2013-10-02 11:24:02 +02:00
parent 007c0e5fe1
commit 3537ad8ae1
1 changed files with 4 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
tests/check/elements/multiqueue.c
View file

@ -739,7 +739,10 @@ multiqueue_suite (void)
tcase_add_test (tc_chain, test_request_pads); tcase_add_test (tc_chain, test_request_pads);
tcase_add_test (tc_chain, test_request_pads_named); tcase_add_test (tc_chain, test_request_pads_named);
tcase_add_test (tc_chain, test_output_order); /* Disabled, The test (and not multiqueue itself) is racy.
* See https://bugzilla.gnome.org/show_bug.cgi?id=708661 */
if (0)
tcase_add_test (tc_chain, test_output_order);
tcase_add_test (tc_chain, test_sparse_stream); tcase_add_test (tc_chain, test_sparse_stream);
return s; return s;