4 billion seconds added to expiry when system time steps backwards

[GoogleCodeExporter]

What steps will reproduce the problem?

As root,

1. date -s '2011-01-06 00:00:59'
2. ./memcached -u nobody -d
3. echo -e "set x 0 1 0\r\n\r" | nc localhost 11211
4. echo stats cachedump 1 0 | nc localhost 11211
5. date -s '2011-01-06 00:00:00'
6. echo -e "set x 0 1 0\r\n\r" | nc localhost 11211
7. echo stats cachedump 1 0 | nc localhost 11211

What is the expected output? What do you see instead?

In step #7, I expect to see the expiry of item "x" to be in the ballpark of 
1294290000s, however I see 5589257300 instead. This means that the cache key 
will practically never expire. Note that 5589257300 - 1294290000 is roughly 
2^32.

What version of the product are you using? On what operating system?

Tested on 1.2.2 and 1.4.5, on Debian 5.0 64-bit.

Please provide any additional information below.

This problem is most likely happen at system boot, when ntpdate corrects a 
server time backwards, but could happen any other time system time is changed 
backwards.

Original issue reported on code.google.com by doubleu...@gmail.com on 6 Jan 2011 at 3:03

Attachments:

• output.txt

[GoogleCodeExporter]

Just made the clock monotonic for 1.4.7... Leaving a test instance running for 
the next week or two to see how much drift there is off reality.

Tests seem to run okay so far. If the clock ends up being wildly inaccurate 
I'll inline the clock_gettime() code, before 1.4.7-final.

People should really adjust clocks *before* starting daemons... but this bug is 
common for other reasons as well.

Original comment by dorma...@rydia.net on 9 Aug 2011 at 10:14

• Changed state: Fixed