[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] squeak.cog.v3 CI tests fail randomly (#436)
notifications at github.com
Fri Oct 25 11:50:37 UTC 2019
The sole instance of `perror("select");` is found in platforms/unix/vm/aio.c
(other in minheadless and RiscOS do not count)
That's inside `aioPoll(long microSeconds)`
What could possibly happen is an invalid timeval...
Either a negative microSeconds or a greater than maximum possible timeout (implementation defined).
The later cannot happen, because microSeconds is a long, and since this is a 32bits VM, the maximum value we can pass is about 2e9 microSeconds (a bit more than 2000 seconds), far from the limit (select man pages tells that the limit is at least 31 days, more than 2e6 seconds!).
Inside the loop, there is a protection against `microSeconds <= 0`, so the only possibility for an invalid timeval is calling `aioPoll` with a negative timeout.
Maybe we should inquire if there is not an edge case in cog.v3 delay handling...
It might be possible that `primitiveSignalAtMilliseconds(void) ` ask for a small delay in the past, leading to a negative `deltaMsecs` that will be wrapped to positive (modulo `MillisecondClockMask` which is a 29 bits mask), which multiplied by 1000, will lead to about 2^39 microseconds `nextWakeupUsecs` increment. For example, 1ms in the past will lead to a negative delay:
when wrapped on 32bits long:
(16r1FFFFFFF-1*1000 \\ (1 << 32-1)) highBit -> 32.
16r1FFFFFFF-1*1000 \\ (1 << 32-1) - (1<<32) -> -1876.
Then `ioRelinquishProcessorForMicroseconds` will invoke `aioSleepForUsecs(realTimeToWait)` with this negative `long realTimeToWait`.
That's only a theory that came to my mind by reading code, this has to be confirmed, but it seems to me that we already solved that kind of flaw in the past... Maybe not for cog.v3?
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev