GNOME Bugzilla – Bug 797154
gstreamer 1.14.3 core fails gst/gstsegment segment_full test on 32bit x86
Last modified: 2018-09-17 12:41:55 UTC
1.14.3 is failing gst/gstsegment test for 32bit builds (including multilib builds on 64bit systems). They seem to be fine in 1.14.2, so looks like a regression. 64bit build seems to be fine (not counting bug 797153 hitting occasionally) FAIL: gst/gstsegment ==================== Running suite(s): GstSegment 90%: Checks: 11, Failures: 1, Errors: 0 /tmp/portage/media-libs/gstreamer-1.14.3/work/gstreamer-1.14.3/tests/check/gst/gstsegment.c:900:F:segments:segment_full:0: Assertion 'pos == 89' failed Check suite gst_segment ran in 0.024s (tests failed: 1) FAIL gst/gstsegment (exit status: 1)
Is this caused by 5978e3b9587ddc998ddf5833ef34a915e02a52dd?
Also fails in master fwiw. Value is 88 instead of 89.
(In reply to Sebastian Dröge (slomo) from comment #1) > Is this caused by 5978e3b9587ddc998ddf5833ef34a915e02a52dd? Of course, that what added that test that compares to 89 :) The failure goes away if just that commit is reverted, but that presumably reintroduces the wrong negation in other cases. Looks like the gst_segment_position_from_running_time_full result is different on 32bit than 64bit with the given input. So then the question is if that's to be expected or a real bug in there..
I think this is going to be some difference in how the floating-point operations get rounded
What fancy stuff are we doing in the test that it breaks rounding behaviour that much? And we're not using -ffast-math, so floats should all be IEEE-compliant including rounding behaviour, or not?
Created attachment 373671 [details] [review] tests: Use a different rate in a segment test. Using a rate of 1.1 in the test is causing the test to fail on 32-bit because ceil(1.1 * 10) can round to 12. Instead use a rate 2.0 that can be expressed as floating point number and doesn't trigger the problem.
Pushed as commit 01758dcf6ad99b8e62108525614267ca2901e8bb