elliefm
commented
2 months ago That chunk of code is:
static int64_t now(void)
{
struct timeval tv = { 0xffffffff, 0xffffffff };
int r = real_gettimeofday(&tv, NULL);
assert(r == 0);
assert(tv.tv_sec != 0xffffffff);
assert(tv.tv_usec != 0xffffffff); // <---- assertion here
return from_timeval(&tv);
}Which is interesting because that's the third assertion, meaning that the other two passed. This means that real_gettimeofday() returned 0 indicating success, and filled out a sensible value into the tv.tv_sec field; only the tv.tv_usec field was unmodified from its original value (causing the assertion). I'm not sure what to make of that.
man gettimeofday on Linux debian 6.1.0-18-amd64 tells me that struct timeval is defined like this:
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};Digging through headers, it looks like suseconds_t is the same underlying type as time_t:
64:#define __TIME_T_TYPE __SYSCALL_SLONG_TYPE
66:#define __SUSECONDS_T_TYPE __SYSCALL_SLONG_TYPEman gettimeofday also says "Traditionally, the fields of struct timeval were of type long," which might explain why we're initialising those fields with 32-bit values even though they should be 64-bit fields on a normal time64 system.
What does struct timeval look like on non-time64 platforms?
What happens if you apply this patch? All it does is change that function to actually initialise (and check) the full 64-bits:
diff --git a/cunit/timeofday.c b/cunit/timeofday.c
index 50e121bf1..0c3effd71 100644
--- a/cunit/timeofday.c
+++ b/cunit/timeofday.c
@@ -106,11 +106,12 @@ static time_t to_time_t(int64_t t)
static int64_t now(void)
{
- struct timeval tv = { 0xffffffff, 0xffffffff };
+ const int64_t init_val = 0xffffffffffffffff;
+ struct timeval tv = { init_val, init_val };
int r = real_gettimeofday(&tv, NULL);
assert(r == 0);
- assert(tv.tv_sec != 0xffffffff);
- assert(tv.tv_usec != 0xffffffff);
+ assert(tv.tv_sec != init_val);
+ assert(tv.tv_usec != init_val);
return from_timeval(&tv);
}
I don't expect it to fix anything, but if it changes the failure, we might learn something from the way the failure changes
guimard
kitterma
From Debian #1068223.
I can launch 3.8.2 build on such architecture if you give me a patch to test.
Best regards,