Hi Ian,
On Wed, Jan 15, 2025 at 07:29:54PM +0000, Ian Jackson wrote:
> It seems that current faketime in sid is capable of persuading
> xapian-omega's upstream tests that faketime is working, but does not
> actually manage to fake it well enough:
>
> 40s expected: «Query((Y2000 ... Y2014 OR M201501 ...
> 40s received: «Query((Y2000 ... Y2024 OR D20250101 ...
Based on the output, it looks to me like faketime isn't affecting
the return value of time(NULL), and testing on amdahhl in an armel
chroot this indeed seems to be the case:
(sid_armel-dchroot)olly@amdahl:~$ cat now.c
#include <stdio.h>
#include <time.h>
int main() { printf("%ld\n", (long)time(NULL)); return 0; }
(sid_armel-dchroot)olly@amdahl:~$ gcc `dpkg-buildflags --get CPPFLAGS` now.c
(sid_armel-dchroot)olly@amdahl:~$ ./a.out
1736980314
(sid_armel-dchroot)olly@amdahl:~$ faketime '1971-01-01' ./a.out
1736980326
However date's idea of the current time *is* affected:
(sid_armel-dchroot)olly@amdahl:~$ faketime '1971-01-01' date +%s
31536000
This seems like an RC bug in faketime to me, especially as the man page
faketime(1) explicitly documents time() as a function which is
intercepted:
Actually, faketime is a simple wrapper for libfaketime, which
uses the LD_PRELOAD mechanism to load a small library which
intercepts system calls to functions such as time(2) and fstat(2).
nm ./a.out seems to show time64 as the function that needs intercepting:
U __time64@GLIBC_2.34
Looking at the source of faketime 0.9.10-2.4 time64() doesn't seem to be
handled currently.
> The test script has code in it to try to detected a busted faketime,
> but it evidently doesn't faithfully test the calls actually used by
> the software under test.
That check was added to detect a particular case of a broken faketime
in the homebrew package on macOS.
> As a result, the tests now fail. Previously, I presume, they
> currently detected that faketime was completely broken, and skipped
> those tests.
>
> Would it be possible to gate these tests on a more faithful test?
Maybe, but it seems we can't detect this problem via date(1) as
the above shows that gets the current time in a different way
which faketime does intercept.
> One stopgap might be to gate the tests with stat(1) as well as
> date(1). faketime is supposed to clamp file timestamps so they don't
> look like they're from the future. So statting any file created
> during the build or the tests, with a very old faked time, would
> suffice. If xapian-omega is using file timestamps, this would
> possibly even be arguably correct.
There aren't any file timestamps involved here so it would certainly be
less correct. It sounds like it could work for this very specific
situation, but requires a portable shell command which calls stat() on a
file and reports something we can check. We could compile a helper I
guess, but if we're going to do that we could compile a helper that just
calls time(), which would actually be testing for the problem we have
here.
I think faketime() with broken support for faking time() shouldn't be
allowed to migrate to testing though, at which point a more complex
check here doesn't seem to be necessary.
Cheers,
Olly
