[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211029210445.GT37904@port70.net>
Date: Fri, 29 Oct 2021 23:04:45 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com,
Érico Nogueira <ericonr@...root.org>
Subject: Re: Re: freeswitch and musl 1.2.x (time64 most likely)
* Sebastian Kemper <sebastian_ml@....net> [2021-10-29 16:40:02 +0200]:
> static void test_now(abts_case *tc, void *data)
> {
> apr_time_t timediff;
> apr_time_t current;
> time_t os_now;
>
> current = apr_time_now();
> time(&os_now);
>
> timediff = os_now - (current / APR_USEC_PER_SEC);
> /* Even though these are called so close together, there is the chance
> * that the time will be slightly off, so accept anything between -1 and
> * 1 second.
> */
> ABTS_ASSERT(tc, "apr_time and OS time do not agree",
> (timediff > -2) && (timediff < 2));
> }
>
> This happens when I run it (the other two "Line" warnings are from
> different tests!):
>
> testtime : |Line 69: apr_time and OS time do not agree
> |Line 110: Mismatch in tm_sec
> |Line 204: expected <Thu Jan 1 01:00:00 1970>, but saw <Sat Sep 14 21:05:36 2002>
> FAILED 3 of 13
> Failed Tests Total Fail Failed %
> ===================================================
> testtime 13 3 23.08%
>
> (gdb) b test/testtime.c:57
> Breakpoint 1 at 0x405837: file testtime.c, line 61.
> (gdb) c
> Continuing.
>
> Breakpoint 1, test_now (tc=0x7fffacd0, data=0x0) at testtime.c:61
> 61 current = apr_time_now();
> (gdb) bt
> #0 test_now (tc=0x7fffacd0, data=0x0) at testtime.c:61
> #1 0x00404b43 in abts_run_test (ts=0x77f0bde0, f=0x40581d <test_now>, value=0x0) at abts.c:171
> #2 0x00406733 in testtime (suite=0x77f0bde0) at testtime.c:300
> #3 0x004055d9 in main (argc=3, argv=0x7fffadb4) at abts.c:429
> (gdb) p current
> $1 = 193277741781
> (gdb) p ¤t
> $2 = (apr_time_t *) 0x7fffac90
> (gdb) p os_now
> $3 = 19521141760827868
> (gdb) p &os_now
> $4 = (time_t *) 0x7fffac88
> (gdb) p timediff
> $5 = 19521141756395521
these values are completely wrong (may be not set up yet,
you cannot rely on line numbers in optimized code)
time on your system now should be around
1635500000
current / 1000000 is
193277
which is 1970-01-03 05:41:17
os_now is far in the future.
> (gdb) p &timediff
> $6 = (apr_time_t *) 0x7fffac98
> (gdb) p time
> $7 = {time32_t (time32_t *)} 0x77fd0b08 <time>
> (gdb) p &time
> $8 = (time32_t (*)(time32_t *)) 0x77fd0b08 <time>
> (gdb) c
> Continuing.
> [Inferior 1 (process 14739) exited with code 01]
> (gdb)
>
> To me it looks like apr is also using a 64 bit type for time. So it's a
> bit of a surprise for me that there is a problem. I find it also strange
> that the time function (which seems to be from libc) seems to be related
> to a 32 bit type.
>
> Can you maybe make sense of this?
you need to debug this further, all sorts of things may be wrong here.
i'd remove all other tests from the test exe and break on gettimeofday
and time and see what the libc returns, also print the time in the test.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
