Changes between Initial Version and Version 7 of Ticket #2848
 Timestamp:
 Dec 6, 2008 3:11:20 PM (8 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #2848
 Property Cc tomasz.zielonka@… mariusz.gadarowski@… przemyslaw.kosiak@… added

Property
Summary
changed from
ThreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC.
tothreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC.

Property
Difficulty
changed from
to
Unknown

Property
Version
changed from
6.10.1
to6.8.1

Property
Architecture
changed from
Unknown/Multiple
tox86

Property
Operating System
changed from
Unknown/Multiple
toLinux

Ticket #2848 – Description
initial v7 2 2 Calling threadDelay at certain clocktime intervals can make the thread 3 3 wait forever. This happens regularly, approximately every 49 days 17 hours, 4 or, more accurately, every (2^32 / 1000)seconds. You can reproduce the bug with4 or, more accurately, every `(2^32 / 1000)` seconds. You can reproduce the bug with 5 5 a simple program, if you set your machine's clock to a specially crafted 6 6 time. … … 70 70 finally divided by interval. lnat is defined as "unsigned long"  on a 71 71 32bit system this is usually a 32bit type. The result of multiplying 72 by 1000 will have its higher bits lost and it will be in the range [0 .. 73 2^32  1]. Dividing it by interval will shrink the range to [0 .. (2^32 74  1) / interval]. With default value of tickInterval  which is 50  75 this will be [0 .. 85899345]. Adding the second part of the expression 76 can only increase it by (999999 / (interval * 1000)), which is equal to 72 by 1000 will have its higher bits lost and it will be in the range `[0 .. 2^32  1]`. Dividing it by interval will shrink the range to `[0 .. (2^32  1) / interval]`. With default value of tickInterval  which is `50`  this will be `[0 .. 85899345]`. Adding the second part of the expression 73 can only increase it by `(999999 / (interval * 1000))`, which is equal to 77 74 19 with default settings. 78 75 79 76 So, for default parameters, the result of getourtimeofday() will be in 80 [0 .. 85899364]. Why is it a problem? It's quite simple: When a thread77 `[0 .. 85899364]`. Why is it a problem? It's quite simple: When a thread 81 78 executes threadDelay the runtime calculates the tick at which it should 82 79 be woken up. In our example, threadDelay is executed at tick 85899266, 83 and the time of wakeup is probably calculated as 85899266 + 5 * (1000 /84 50) = 85899366. This is greater then the biggest value getourtimeofday() 80 and the time of wakeup is probably calculated as 81 `85899266 + 5 * (1000 / 50) = 85899366`. This is greater then the biggest value `getourtimeofday()` 85 82 can return. 86 83