The 2038 problem

Specifications

  • Versions: 1.00a - 1.01a - 1.01b - 1.01c - 1.02a
  • Shottype: Aya
  • Scenes: Any

What happens

If your operating system's time is after the timestamp 19th of January 2038, 03:14:07 UTC, your game will likely crash.

xkcd 607 is shown, describing the issue of the year 2038.
Figure 1: Relevant xkcd (https://xkcd.com/607/).

How it happens

This happens if your operating system's time is after the timestamp 19th of January 2038, 03:14:07 UTC. The crash has multiple ways of taking place, which are listed as follows:

  1. The crash happens on saving a replay (offset: tobedone)

Why it happens

When saving player data, one of the values needed is the current time. For the game to get your operating system's current time, the following code is run when it needs the current time:

using time32_t = int32_t;

time32_t __time32(time32_t* out)
{
    FILETIME ft;
    GetSystemTimeAsFileTime(&ft);

    // Official Windows way to convert FILETIME -> 64‑bit integer
    ULARGE_INTEGER u;
    u.LowPart  = ft.dwLowDateTime;
    u.HighPart = ft.dwHighDateTime;

    uint64_t filetime = u.QuadPart;

    static const uint64_t EPOCH_DIFF = 116444736000000000ULL;

    uint64_t unixSeconds = (filetime - EPOCH_DIFF) / 10000000ULL;

    // The 2038 overflow happens here !!!
    time32_t result = static_cast<time32_t>(unixSeconds);

    if (out)
        *out = result;

    return result;
}

(For technical readers, the assembly code can be found at an offset 0x486406 in 1.02a.)

This code fetches the operating system's time, converts it to Unix time based on the Unix epoch, and returns this 32-bit Unix timestamp.

Overflow

The Unix time32_t data type that represents a point in time is a 32-bit signed integer. A signed 32-bit time value covers about 68 years before and after the Unix epoch (Jan 1st, 1970): the minimum date is Friday 1901-12-13, and the maximum date is Tuesday 2038-01-19. One second after the 19th of January 2038, 03:14:07 UTC, time32_t overflows. This issue is also known as the Year 2038 Problem.

When time32_t overflows, the signs "flips", meaning that the time time32_t actually represents is now in the year 1901. Below is a table showing the correct time along with the bugged time.

Actual time Unix time Bugged time
2038-01-19 03:14:05 UTC 2147483645 (0x7FFFFFFD) 2038-01-19 03:14:05 UTC
2038-01-19 03:14:06 UTC 2147483646 (0x7FFFFFFE) 2038-01-19 03:14:06 UTC
2038-01-19 03:14:07 UTC 2147483647 (0x7FFFFFFF) 2038-01-19 03:14:07 UTC
2038-01-19 03:14:08 UTC -2147483648 (0x80000000)
1901-12-13 20:45:52 UTC
2038-01-19 03:14:09 UTC -2147483647 (0x80000001)
1901-12-13 20:45:53 UTC
2038-01-19 03:14:10 UTC -2147483646 (0x80000002)
1901-12-13 20:45:54 UTC

For the first 2^31 - 1 values of unix time, the value is displayed correctly. When it surpasses 2^31 - 1, the integer overflows and wraps around to a negative value.

The Crash

There are several parts in the code where time32_t is used. However, for simplicity we will only focus on one part.

Consider the following pseudo-code, which is run when saving a replay:

void FormatReplayString(char *buffer)
{
    __time32_t t;
    struct tm *tm_info;

    // Get current time as 32-bit time_t
    __time32(&t);

    // Convert to local time structure
    tm_info = _localtime(&t);

    // Format the string in some way
    format_string(buffer, tm_info);
}

(The code is more complicated than this and cannot be found in just one function call, instead it is separated between multiple calls.)

As established before, t, would have a negative value. This in itself doesn't crash the system. When t is passed into _localtime, it returns null as its value. When this null pointer value gets passed into format_string, it eventually leads to a crash.

Replays

Since this bug involves a consistent crash at a given time, it is not possible to create a replay that comes from after 2038.

Videos

Other