Closed fixindan closed 5 months ago
Thanks for reporting this. Could you please share some details about which OS/Linux distribution and glibc version you are using?
We had a long-standing series of issues with "hangs" on monotonic clock usage, which led to the FORCE_MONOTONIC_FIX compile-time flag and environment variable, and internal functions like needs_forced_monotonic_fix() to determine the need for this "fix" based on the glibc version in use. Historically, ARM64 was the first platform to show this behaviour and back then it was assumed to be platform- instead of glibc-version-specific. However, so far we only got reports about long "hangs", not about premature timeouts.
Could you try whether it works as expected when removing the two relevant #ifndefs for __ARM_ARCH?
https://github.com/wolfcw/libfaketime/blob/6fc4ae74f43bd906be74515778c35b2658672958/src/libfaketime.c#L351 https://github.com/wolfcw/libfaketime/blob/6fc4ae74f43bd906be74515778c35b2658672958/src/libfaketime.c#L3756
Thank you for the quick follow up. This issue was observed several months back and I no loner remember all the details. It will take me some time to get everything set up again to try and reproduce the issue. I'll try to hopefully follow up on this next week.
I've tried to compile the code with and without
FORCE_MONOTONIC_FIX
and neither worked. My condition variable timed wait timed out almost immediately after being called no matter how large the timeout value is; this was happening 100% of the time. After much trial and error I've discovered that by settingfake_monotonic_clock
to 1 for ARM64 platform seemed to work, but the code specifically setfake_monotonic_clock
to 0 for ARM64 platform. I'm still not sure why the premature timeouts occur on ARM64 platform and if settingfake_monotonic_clock
to 1 is the right thing to do. If not, please advice what I should do instead.