Changes between Initial Version and Version 7 of Ticket #2848


Ignore:
Timestamp:
Dec 6, 2008 3:11:20 PM (7 years ago)
Author:
igloo
Comment:

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. to threadDelay 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 to 6.8.1
    • Property Architecture changed from Unknown/Multiple to x86
    • Property Operating System changed from Unknown/Multiple to Linux
  • Ticket #2848 – Description

    initial v7  
    22Calling threadDelay at certain clock-time intervals can make the thread 
    33wait forever. This happens regularly, approximately every 49 days 17 hours, 
    4 or, more accurately, every (2^32 / 1000) seconds. You can reproduce the bug with 
     4or, more accurately, every `(2^32 / 1000)` seconds. You can reproduce the bug with 
    55a simple program, if you set your machine's clock to a specially crafted 
    66time. 
     
    7070finally divided by interval. lnat is defined as "unsigned long" - on a 
    717132-bit system this is usually a 32-bit 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 
     72by 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 
     73can only increase it by `(999999 / (interval * 1000))`, which is equal to 
    777419 with default settings. 
    7875 
    7976So, for default parameters, the result of getourtimeofday() will be in 
    80 [0 .. 85899364]. Why is it a problem? It's quite simple: When a thread 
     77`[0 .. 85899364]`. Why is it a problem? It's quite simple: When a thread 
    8178executes threadDelay the runtime calculates the tick at which it should 
    8279be woken up. In our example, threadDelay is executed at tick 85899266, 
    83 and the time of wake-up is probably calculated as 85899266 + 5 * (1000 / 
    84 50) = 85899366. This is greater then the biggest value getourtimeofday() 
     80and the time of wake-up is probably calculated as 
     81`85899266 + 5 * (1000 / 50) = 85899366`. This is greater then the biggest value `getourtimeofday()` 
    8582can return. 
    8683