Created attachment 208470 [details] [review]
Use g_get_current_time and try twice

To reproduce the bug, I run the GstDateTime unit tests test_GstDateTime_now and test_GstDateTime_utc_now, "forever":

GST_CHECKS=test_GstDateTime_now,test_GstDateTime_utc_now make -C tests/check gst/gstdatetime.forever

Within 10 seconds, I get a failure like the following:

Running suite(s): GstDateTime
50%: Checks: 2, Failures: 1, Errors: 0
gst/gstdatetime.c:52:F:general:test_GstDateTime_now:0: 'gst_date_time_get_second (dt)' (45) is not equal to 'tm.tm_sec' (44)

I've attached a proposed patch for this bug. The tests use the Linux system call time() for getting a time reference, and then call the tested functions gst_date_time_new_now_local_time and gst_date_time_new_now_utc. The tests expect to get times within the same second. We've found that there are two things that can cause the failure:

1) The Linux system call time() and g_get_current_time don't always return a time with the same second component, even if they are called simultaneously.
2) Between two calls that ask what time it is, some time may pass and we might simply get different seconds for that reason.

Regarding 1), I've changed from using time() to using g_get_current_time in the tests. g_get_current_time is used by the tested functions, and itself uses the system call gettimeofday. Some measurements showed that, on my system, time() switched over to a new seconds about 2-3 milliseconds later than gettimeofday. I.e., when I got the second 45 from gettimeofday, I could call time() many times during about 2-3 milliseconds, and still get 44. This may have to do with the different granularities of time() and gettimeofday.

Regarding 2), I added a while loop that tries twice if the tests get different seconds.