From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 1215 invoked from network); 29 Oct 2021 21:05:02 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 29 Oct 2021 21:05:02 -0000
Received: (qmail 1298 invoked by uid 550); 29 Oct 2021 21:04:58 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 1258 invoked from network); 29 Oct 2021 21:04:57 -0000
Date: Fri, 29 Oct 2021 23:04:45 +0200
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com,
	=?utf-8?B?w4lyaWNv?= Nogueira <ericonr@disroot.org>
Message-ID: <20211029210445.GT37904@port70.net>
Mail-Followup-To: musl@lists.openwall.com,
	=?utf-8?B?w4lyaWNv?= Nogueira <ericonr@disroot.org>
References: <YXsXSK9QcBDiQpKV@darth.lan>
 <CFBK7OCAFVQZ.1C1N6J5HVJ5C9@mussels>
 <YXwHwtjsgtbvlZQl@darth.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YXwHwtjsgtbvlZQl@darth.lan>
Subject: Re: [musl] Re: freeswitch and musl 1.2.x (time64 most likely)

* Sebastian Kemper <sebastian_ml@gmx.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 &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

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.