GNOME Bugzilla – Bug 768723
rtprtx: test is sometimes failing
Last modified: 2016-11-27 11:23:40 UTC
The 'elements/rtprtx' test is sometimes failing here with master. elements/rtprtx.c:163:F:general:test_push_forward_seq:0: 'nbrtxpackets' (2) is not equal to '3' (3)
I could swear there's a bug for this already, but can't find it right now. Has been failing for eternities, possibly since rtx support was added.
I also observed this one: gstcheck.c:391:F:general:test_rtxreceive_data_reconstruction:0: check pad_peer (0x18324e0) refcount is 3 instead of 2 Here is the full logs as well: http://people.collabora.co.uk/~cassidy/gst-bgo768723.log.gz
There is also this one : test_rtxsend_rtxreceive:0: 'rtx_packets' (4) is not equal to 'packets_num' (5) After digging further, the issue is a bit ... stupid. rtx_packets is a counter which is incremented in rtprtxsend *after* the buffer was pushed. So sometimes when you query the value ... it hasn't incremented it yet (just after the push). Is there a way we can guarantee with harness that the push has completely come back ?
Maybe Håvard has an idea?
(In reply to Sebastian Dröge (slomo) from comment #4) > Maybe Håvard has an idea? If you pull out all buffers (with gst_harness_pull()) you get this guarantee. Maybe the test does not completely pull out all available ones? (a classic source of race-conditions!)
Created attachment 340836 [details] [review] rtprtxsend: Update statistics before pushing If an element queries the number of retransmission buffers pushed *while* the push is still taking place (and before the object lock is taken just after) it would end up with the wrong statistic being reported. Increment it just before the push, avoids races when getting statistics
commit 91f5b4eaa2fcd874361d16bdf80497c3cdd12d13 Author: Edward Hervey <edward@centricular.com> Date: Sun Nov 27 11:14:13 2016 +0100 rtprtxsend: Update statistics before pushing If an element queries the number of retransmission buffers pushed *while* the push is still taking place (and before the object lock is taken just after) it would end up with the wrong statistic being reported. Increment it just before the push, avoids races when getting statistics https://bugzilla.gnome.org/show_bug.cgi?id=768723