Menu
▾
▴
#94 Wrapper.exe fails in year 2038
While I understand this is far off in the future, it is part of
our testing to check this condition. The wrapper
executable fails to function in 2038 and will enter a brief
infinite loop before terminating unexpectedly.
This could be related to the "2038 bug" (see
http://www.2038bug.com/ ) where the 31 bits of the
integer used to store time overflow into the 32nd bit
used for sign. The 31 bits give us about 68 years of
time from the "epoch", or 01/01/1970, in seconds
causing a y2k style jump back in time to 12/13/1901
when time overflows into the 32nd bit.
Why I say could be related to is because theoretically
the program should still function after 2038, just with a
horribly inaccurate date. I understand this could be
anything from simple to extremely difficult to fix.
Thanks in advance,
Thomas
Logged In: YES
user_id=1323301
I forgot to mention that I am on Windows 2k and Windows
XP, although I don't think it makes any difference. I did see
that in wrapper.c "ftime" is being used
in "wrapperGetSystemTicks", which populates a structure
that has only 32 bits to store seconds. I agree with your
comment in wrapperGetTickAge that even if it rolls over
subtraction will always work... but something somewhere
isn't handling this properly. I am no expert on any of this, so
I very well could have missed something, just my thoughts.