mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Sebastian Kemper <>
Cc: "Érico Nogueira" <>
Subject: Re: [musl] Re: freeswitch and musl 1.2.x (time64 most likely)
Date: Fri, 29 Oct 2021 16:40:02 +0200	[thread overview]
Message-ID: <YXwHwtjsgtbvlZQl@darth.lan> (raw)
In-Reply-To: <CFBK7OCAFVQZ.1C1N6J5HVJ5C9@mussels>

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();

    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

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
[Inferior 1 (process 14739) exited with code 01]

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,

  reply	other threads:[~2021-10-29 14:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27 22:16 [musl] " Sebastian Kemper
2021-10-27 23:24 ` Érico Nogueira
2021-10-28 20:21 ` [musl] " Sebastian Kemper
2021-10-28 21:34   ` Sebastian Kemper
2021-10-29  3:10     ` Érico Nogueira
2021-10-29 14:40       ` Sebastian Kemper [this message]
2021-10-29 21:04         ` Szabolcs Nagy
2021-10-29 22:44           ` Sebastian Kemper
2021-10-30  1:00             ` Rich Felker
2021-10-30 10:57               ` Sebastian Kemper
2021-10-30 17:56                 ` Rich Felker
2021-10-30 19:07                   ` Sebastian Kemper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YXwHwtjsgtbvlZQl@darth.lan \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).