Re: [musl] Re: freeswitch and musl 1.2.x (time64 most likely)

[Sebastian Kemper <sebastian_ml@gmx.net>]

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 &current
$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