GNOME Bugzilla – Bug 746445
rtpaux: Unit test is racy and producing warnings
Last modified: 2015-08-16 13:39:57 UTC
Same as bug #728501. It works more often now it seems, but still deadlocks every now and then. Also it produces warnings now: Unexpected critical/warning: gstpad.c:4798:store_sticky_event:<rtpsession1:sync_src> Sticky event misordering, got 'segment' before 'caps' 0%: Checks: 1, Failures: 1, Errors: 0 gstcheck.c:79:F:general:test_simple_rtpbin_aux:0: Unexpected critical/warning: gstpad.c:4798:store_sticky_event:<rtpsession1:sync_src> Sticky event misordering, got 'segment' before 'caps'
The warning is gone but the test is still racy and sometimes fails commit 0e3609a6e12cc44a4d83cabed910422c2e91a5b8 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sat Mar 21 17:50:40 2015 +0100 rtpsession: Fix another instance of sticky event misordering warnings Make sure that the sync_src pad has caps before the segment event. Otherwise we might get a segment event before caps from the receive RTCP pad, and then later when receiving RTCP packets will set caps. This will results in a sticky event misordering warning This fixes warnings in the rtpaux unit test but also in the rtpaux and rtx examples in tests/examples/rtp https://bugzilla.gnome.org/show_bug.cgi?id=746445
For me it fails reliable, every single time, with: elements/rtpaux.c:388:F:general:test_simple_rtpbin_aux:0: Failure 'nb_rtx_send_packets < 1' occurred
commit 5f9e5bf385d3851ce1b84fc560f9362559c2c154 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Tue Aug 4 18:07:35 2015 -0300 tests: rtpaux: fix test failure The RTP PT for alaw is 8. Less than 50 packets are received in the length of this test so it would never drop a buffer or would drop only the last buffer and it would fail sometimes when the received wouldn't receive the retransmission packet in time. https://bugzilla.gnome.org/show_bug.cgi?id=746445
Created attachment 308757 [details] [review] tests: rtpaux: fix to set valid payload type to pt-map Thiago's patch makes this unit test successful. I think setting payload type to pt-map needs to be changed also even though it doesn't affect this unit test.
Created attachment 308758 [details] [review] rtprtxsend: print valid type where guint32 is expected When I'm investigating, I found something to print wrong value, which is mis-type printing.
Ah, it seems like I overlooked that the pt type was being explicitly set. Will revisit this tomorrow.
Created attachment 308794 [details] [review] tests: rtpaux: use a dynamic pt in the test 1) Tests that using dynamic PT instead of the default ones work 2) If we ever decide to change the codec here we don't need to worry about change the PT for the default one of the new codec in the test
The real blocker is #747965, after that is fixed we can push the new update to the tests to make them use pt=96 again and this should be all solved.
Indeed. I tested again with #747965's patch and your second patch. Seems to be sloved. Anyway, my second patch to print out ssrc value properly can be merged? :)
commit dac431ef3fee58870db21005b89650b892524cdd Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Wed Aug 5 11:13:09 2015 -0300 tests: rtpaux: use a dynamic pt in the test 1) Tests that using dynamic PT instead of the default ones work 2) If we ever decide to change the codec here we don't need to worry about change the PT for the default one of the new codec in the test https://bugzilla.gnome.org/show_bug.cgi?id=746445 commit b0d602086251c7ab435b6845884e4b0be277a218 Author: Hyunjun Ko <zzoon.ko@samsung.com> Date: Wed Aug 5 10:53:15 2015 +0900 rtprtxsend: print valid type where guint32 is expected https://bugzilla.gnome.org/show_bug.cgi?id=746445
Comment on attachment 308758 [details] [review] rtprtxsend: print valid type where guint32 is expected >From: Hyunjun Ko <zzoon.ko@samsung.com> >Subject: [PATCH] rtprtxsend: print valid type where guint32 is expected > GST_DEBUG_OBJECT (rtx, >- "got caps for payload: %d->%d, ssrc: %u->%d: %" GST_PTR_FORMAT, >- payload, GPOINTER_TO_INT (rtx_payload), ssrc, data->rtx_ssrc, caps); >+ "got caps for payload: %d->%d, ssrc: %u->%" G_GUINT32_FORMAT ": %" >+ GST_PTR_FORMAT, payload, GPOINTER_TO_INT (rtx_payload), ssrc, >+ data->rtx_ssrc, caps); For what it's worth, I think %u would probably have been just fine, integer types <sizeof(int) should get promoted to integer size when being passed through vararg functions, so I suspect it was just a signed/unsigned mix-up here?
> > For what it's worth, I think %u would probably have been just fine, integer > types <sizeof(int) should get promoted to integer size when being passed > through vararg functions, so I suspect it was just a signed/unsigned mix-up > here? Yes. It printed negative value when I'm testing