>Number:         28391
>Category:       xsrc
>Synopsis:       X and date change forward causes temporary freeze
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 23 04:33:00 +0000 2004
>Originator:     David H. Gutteridge
>Release:        i386/2.0_RC4 and macppc/1.6.1
>Organization:
>Environment:
>Description:
Changing the date forward in an X terminal (xterm, wterm, et. al.) by a large amount causes X (and any other userland app) to freeze.  I discovered this by accident because of a combination of a bug in the date command and user error (to be reported separately).  The amount of time userland freezes for appears proportional to the amount of time the date is moved forward by.  I tested on my iBook as far out as 2020, and in that case it was frozen for well over an hour.

Here are some results I recorded on a Dell Precision 410 workstation with two 350MHz Pentium IIs running 2.0_RC4 GENERIC.MP:

Moving date forward six months: 26 second freeze
Moving date forward one year: 84 second freeze
Moving date forward two years: 175 second freeze

Note that this problem doesn't occur when moving the date backwards.  I know nothing about X internals, so I have no idea if that's significant or not.

I tried this with Blackbox, WindowMaker, and Enlightenment, with both xterm and wterm, and the results are identical.  The X server itself is running as root, the other processes are running as a regular user (I haven't changed anything from the stock NetBSD setup).  As per Martin Husemann's suggestion, I tried changing the date via a remote ssh session, and that didn't cause a freeze, so it appears it's localized within X.

Per Steven Bellovin's suggestion, I also had a look to see if anything other than X could be contributing.  Here's what I tried: I removed the root crontab file (no other users have crontabs), I made a date change one year forward, and the results were:

X server before: 0:02 CPU time
X server after: 1:29 CPU time

lastcomm shows no processes between the date command I issued and the time the system unfroze.  No other processes show any major changes.  So it appears X is indeed the culprit.

I imagine this is a very uncommonly encountered problem, as I doubt many  people will be making major date changes on their machines while in X.  It's probably most likely to happen through accidents like mine.

(See also the thread on this problem in the late November 2004 tech-x11 mailing list archives, titled "X and date change causes hang".)
>How-To-Repeat:
Open a terminal under X, su to root, change the date forward by a significant amount, e.g. six months.
>Fix:
No fix known, sorry.