Closed vcunat closed 1 year ago
This behavior of python only starts with 3.11, but the bug really seems to be in faketime.
I don't know faketime codebase, but I'd expect that when --exclude-monotonic
is active, it wouldn't touch the timestamp, so e.g.
--- a/src/libfaketime.c
+++ b/src/libfaketime.c
@@ -1359 +1359 @@ int clock_nanosleep(clockid_t clock_id, int flags, const struct timespec *req, s
- else if (clock_id == CLOCK_MONOTONIC)
+ else if (clock_id == CLOCK_MONOTONIC && fake_monotonic_clock)
or perhaps with some details changed, like re-reading from env vars, e.g. (my ugly code)
--- a/src/libfaketime.c
+++ b/src/libfaketime.c
@@ -1359 +1359,2 @@ int clock_nanosleep(clockid_t clock_id, int flags, const struct timespec *req, s
- else if (clock_id == CLOCK_MONOTONIC)
+ else if (clock_id == CLOCK_MONOTONIC &&
+ (get_fake_monotonic_setting(&fake_monotonic_clock), fake_monotonic_clock))
This diff fixes the trivial test case above, at least.
Commit d17bb11 does not fix the issue for me - the OSError
remains unchanged. @vcunat's second patch with the get_fake_monotonic_setting
call seems to do the trick.
hm, somewhat weird, since this should be handled by initialisation even if clock_nanotime() is the first call. Added the explicit update as outlined be @vcunat ... could you give it another spin?
Sounds weird. I believe that in our use case we trigger it only like faketime --exclude-monotonic
, not by setting during runtime. EDIT: but I haven't verified faketime's startup code in any way.
Wait... isn't the problem that you need to do else { real_req = *req; }
which your change does not? (contrary to mine)
I mean, I haven't studied the code in detail, but the else-part was exactly why I was writing it in such an ugly condition.
you're absolutely right
So this get_*
is probably not needed, but it shouldn't matter. I don't expect it would be a noticeable overhead.
I can confirm the latest commit works
Looks good to me now.
Simple test case:
What happens is that python calls
and with this setting faketime fumbles, passes a negative time to the kernel syscall, which is how EINVAL happens.