Debian Patches

Status for faketime/0.9.10+2024-06-05+gba9ed5b2-0.6

Patch Description Author Forwarded Bugs Origin Last update
interpose-clock_gettime64.patch Interpose clock_gettime64
Since debian generally added 64-bit time support on 32-bit
arches, now glibc sometimes calls the clock_gettime64 syscall
(and library wrapper). This function was missing, and is added here.



This patch is part of an upstream MR:
https://github.com/wolfcw/libfaketime/pull/487		 Helge Deller <deller@gmx.de> no 2025-01-12
0002-Fix-interposition-of-clock_gettime64.patch Fix interposition of clock_gettime64
timespec.tv_nsec is 32-bit, even though timeval.tv_usec is
64-bit (weirdly). This doesn't matter very much in practice because
* on little endian architectures (which is all our 32-bit release
arches) writing to a too big integer ends up writing the
desired value in the desired location, and
* it doesn't affect the overall struct size on any of our actual
architectures (which align the uint64_t to 8 so must make the
whole struct 16 not 12), so the write overflow is harmless.

> #include <time.h>
> #include <sys/time.h>
> #include <stdio.h>
> struct timeval tv;
> struct timespec ts;
> int main(void) {
> printf("time_t %lld\n", (unsigned long long) sizeof(time_t));
> printf("timeval %lld %lld %lld\n",
> (unsigned long long) sizeof(tv),
> (unsigned long long) sizeof(tv.tv_sec),
> (unsigned long long) sizeof(tv.tv_usec)
> );
> printf("timespec %lld %lld %lld\n",
> (unsigned long long) sizeof(ts),
> (unsigned long long) sizeof(ts.tv_sec),
> (unsigned long long) sizeof(ts.tv_nsec)
> );
> }
> (sid_armhf-dchroot)iwj@amdahl:~/Faketime/test$ gcc t.c
> (sid_armhf-dchroot)iwj@amdahl:~/Faketime/test$ ./a.out
> time_t 8
> timeval 16 8 8
> timespec 16 8 4
> (sid_armhf-dchroot)iwj@amdahl:~/Faketime/test$

This patch is part of an upstream MR:
https://github.com/wolfcw/libfaketime/pull/487		 Ian Jackson <ijackson@chiark.greenend.org.uk> no 2025-01-17
0003-Interpose-__time64.patch Interpose __time64
This patch is part of an upstream MR:
https://github.com/wolfcw/libfaketime/pull/487		 Ian Jackson <ijackson@chiark.greenend.org.uk> no 2025-01-17
0004-Interpose-gettimeofday64.patch Interpose gettimeofday64
This patch is part of an upstream MR:
https://github.com/wolfcw/libfaketime/pull/487		 Ian Jackson <ijackson@chiark.greenend.org.uk> no 2025-01-17
0005-Re-disable-faking-utime-by-default.patch Re-disable faking utime by default
Fixes
https://github.com/wolfcw/libfaketime/issues/483

See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093412#35
Hopefully this will fix Debian #1093412.

This patch is now upstream MR
https://github.com/wolfcw/libfaketime/pull/486		 Ian Jackson <ijackson@chiark.greenend.org.uk> no 2025-01-19
0006-Replace-data-race-with-use-of-pthread_once-ftpl_init.patch Replace data race with use of pthread_once (ftpl_init)
At the cost of no longer nicely detecting recursive initialisation
problems.


This patch is part of an upstream MR:
https://github.com/wolfcw/libfaketime/pull/488		 Ian Jackson <ijackson@chiark.greenend.org.uk> no 2025-01-21
0007-Replace-data-race-with-use-of-pthread_once-ft_shm_in.patch Replace data race with use of pthread_once (ft_shm_init)
This patch is part of an upstream MR:
https://github.com/wolfcw/libfaketime/pull/488		 Ian Jackson <ijackson@chiark.greenend.org.uk> no 2025-01-21
0008-Call-ftpl_init-before-using-monotonic_conds_lock.patch Call ftpl_init before using monotonic_conds_lock
Otherwise we can use this in an uninitialised state, which is not
allowed.

We call ftpl_init in pthread_cond_init_232, but the application might
not have called that. For example, it might have a static condition
variable set up with PTHREAD_COND_INITIALIZER.

This patch is part of an upstream MR:
https://github.com/wolfcw/libfaketime/pull/488		 Ian Jackson <ijackson@chiark.greenend.org.uk> no 2025-01-22
0009-Don-t-use-_try_-locking-calls-for-monotonic_conds_lo.patch Don't use _try_ locking calls for monotonic_conds_lock
This reverts commit 8ef74e33b636a53a757a945d8ebc51d0986f0d81
"Swapped out pthread_rwlock_xxlock() ..."

This could result in concurrent uses of pthread_cond_* erroneously
returning EAGAIN, which is not permitted by the spec and which the
application way well treat as a bug. This seems to be happening in
gem2deb in ci.Debian.net.

The commit message in 8ef74e33b636 says (rewrapped)

Swapped out pthread_rwlock_xxlock(), which doesn't return if it
can't obtain the lock, with pthread_rwlock_xxtrylock() followed by
sched yield and error code return. The issue is sometimes a thread
calling pthread_cond_init() or pthread_cond_destroy() can't
acquire the lock when another thread is waiting on a condition
variable notification via pthread_cond_timedwait(), and thus the
thread calling pthread_cond_init() or pthread_cond_destroy() end
up hanging indefinitely.

I don't think this is true. The things that are done with
monotonic_conds_lock held are HASH_ADD_PTR HASH_FIND_PTR etc. on
monotonic_conds, which should all be fast and AFAICT don't in turn
take any locks. So it shouldn't deadlock.

I conjecture that the underlying bug being experienced by the author
of "Swapped out pthread_rwlock_xxlock" was the lack of ftpl_init - ie,
access to an uninitialised pthread_rwlock_t. That might result in a
hang.

This patch is part of an upstream MR:
https://github.com/wolfcw/libfaketime/pull/488		 Ian Jackson <ijackson@chiark.greenend.org.uk> no 2025-01-22
0010-485.patch [PATCH] test/libmallocintercept.c: fix write function unused return value

We should ignore the return value for logging function, to fix a new gcc ftbfs
libmallocintercept.c: In function ‘print_msg’:
libmallocintercept.c:27:9: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
27 | write(0, msg, strlen(msg));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~


This was merged upstream in this MR:
https://github.com/wolfcw/libfaketime/pull/485		 Gianfranco Costamagna <locutusofborg@debian.org> no 2025-01-22

All known versions for source package 'faketime'

Links