[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 Oct 2021 16:40:02 +0200
From: Sebastian Kemper <sebastian_ml@....net>
To: musl@...ts.openwall.com
Cc: Érico Nogueira <ericonr@...root.org>
Subject: Re: Re: freeswitch and musl 1.2.x (time64 most likely)
Am Fri, Oct 29, 2021 at 12:10:05AM -0300 schrieb Érico Nogueira:
>
> Line 3554 is:
>
> sql = switch_mprintf("delete from registrations where expires > 0 and expires <= %ld and hostname='%q'", now, switch_core_get_switchname());
>
> It's using '%ld' for 'now', which is time_t. Will add a commit to fix it
> in my PR. Replace with '%lld' if you want to do a quick fix to see if
> you catch any other errors.
>
Thanks! The segfault now doesn't happen anymore.
Now freeswitch seems to loop around (unusable). The log is plastered
with these messages:
1970-01-01 00:36:58.-797115 23.33% [CRIT] switch_time.c:1203 Virtual Migration Detected! Syncing Clock
1970-01-01 00:36:58.-797115 23.33% [INFO] switch_time.c:626 Clock synchronized to system time.
1970-01-01 00:36:58.-797115 23.33% [CRIT] switch_time.c:1203 Virtual Migration Detected! Syncing Clock
1970-01-01 00:36:58.-797115 23.33% [INFO] switch_time.c:626 Clock synchronized to system time.
I have a hunch that that is an issue with libapr, which freeswitch has
bundled. Incidentally, a few days ago I was playing around with mod php
and apache (which I'm sure you know uses apr). I put up a small php
website which shows the date and time. And whenever I hit F5 in the
browser it would give me a different wrong time and date, but always
around 1970.
I found that apr bundles a test suite. This also includes a test called
"testtime". It finds that the apr time is way different compared to OS
time. Code snippet:
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
(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?
Kind regards,
Seb
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.
