summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEdward Hervey <edward@collabora.com>2013-10-02 11:24:02 +0200
committerEdward Hervey <edward@collabora.com>2013-10-02 11:26:09 +0200
commit3537ad8ae1ea00b31d80b10d8667dfbb9df222d4 (patch)
tree8e1b5b1c657f2b821fe837208a01a087eee78567
parent007c0e5fe155abbc3fc0d801c47ba7388cda3f48 (diff)
check: Disable multiqueue test_output_order check
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
-rw-r--r--tests/check/elements/multiqueue.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/tests/check/elements/multiqueue.c b/tests/check/elements/multiqueue.c
index 651ff7d74..2ec920f36 100644
--- a/tests/check/elements/multiqueue.c
+++ b/tests/check/elements/multiqueue.c
@@ -739,7 +739,10 @@ multiqueue_suite (void)
tcase_add_test (tc_chain, test_request_pads);
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);
return s;