Open robbert-ef opened 1 year ago
Thanks for reporting. Might be related to how the struct timespec is defined on the system for 32 vs 64 bit processes, as it is used as a part of the shared memory libfaketime uses.
As a workaround, does it help to explicitly unset FAKETIME_SHARED before starting the child process? Also, I assume this only happens when already the parent process is started with libfaketime preloaded?
correct! issue only occurs when libfaketime is loaded in the parent process using LD_PRELOAD. explicitly unsetting FAKETIME_SHARED resolves the issue for the example:
LD_PRELOAD=libfaketime.so FAKETIME=+60d bash -c 'unset FAKETIME_SHARED; ./test'
Hello, World!
This however is not a workaround for me as the child process in my use-case is a 32-bit python interpreter started from pyenv. I have no control on when the 32-bit process is started. This can also be the case for other applications in which a 32-bit process is used.
Maybe add an option to not share sem/shm? for example by setting FAKETIME_SHARED=0
?
For now I will stick to 0.9.7 which is working without problem
libfaketime seems to hang forever when a 32-bit process is started when libfaketime is available for 64 and 32-bit
Tested using 0.9.10
steps to reproduce:
1: build libfaketime for both 32 and 64-bit
2: build 32-bit example
test.c
compile:
3: run
starting the 32-bit process:
when trying to start from within a 64-bit process, it hangs forever:
output from gdb, attached to the 32-bit process:
output from strace:
it seems the process is using the shared shm/sem from the parent process (19240) this is broken since 0.9.8, in which FAKETIME_SHARED is used for passing the semaphore and shared memory.