Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing

[kevinwatters]

BPO	4379
Nosy	@loewis, @amauryfa, @abalkin, @vstinner, @tiran, @miss-islington
PRs	bpo-4379: Skip TLS 1.0/1.1 tests under OpenSSL 3.0.0 (GH-25304) #25304 [3.9] bpo-43791: Skip TLS 1.0/1.1 tests under OpenSSL 3.0.0 (GH-25304) #25307 [3.8] bpo-43791: Skip TLS 1.0/1.1 tests under OpenSSL 3.0.0 (GH-25304) #25308
Files	time_t_64.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-02-17.22:13:01.756>
created_at = <Date 2008-11-21.17:20:05.794>
labels = ['type-bug']
title = 'Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing'
updated_at = <Date 2021-04-09.14:08:39.986>
user = 'https://bugs.python.org/kevinwatters'

bugs.python.org fields:

activity = <Date 2021-04-09.14:08:39.986>
actor = 'miss-islington'
assignee = 'none'
closed = True
closed_date = <Date 2011-02-17.22:13:01.756>
closer = 'vstinner'
components = ['None']
creation = <Date 2008-11-21.17:20:05.794>
creator = 'kevinwatters'
dependencies = []
files = ['12101']
hgrepos = []
issue_num = 4379
keywords = ['patch']
message_count = 8.0
messages = ['76193', '76201', '76204', '77506', '128762', '128763', '390620', '390630']
nosy_count = 7.0
nosy_names = ['loewis', 'amaury.forgeotdarc', 'belopolsky', 'vstinner', 'christian.heimes', 'kevinwatters', 'miss-islington']
pr_nums = ['25304', '25307', '25308']
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue4379'
versions = ['Python 2.6', 'Python 2.7']

[kevinwatters]

After releasing a Py_DEBUG build to some users who were experiencing
problems, I noticed a pattern in some of the crash reports I got back:

msvcr90d!_wassert+0xb64
python25_d!FILE_TIME_to_time_t_nsec+0xac
python25_d!attribute_data_to_stat+0x67
python25_d!win32_wstat+0x6f
python25_d!posix_do_stat+0x51
python25_d!posix_stat+0x24
python25_d!PyCFunction_Call+0x65
python25_d!call_function+0x34f
python25_d!PyEval_EvalFrameEx+0x4741

The only way I can see _wassert being hit in FILE_TIME_to_time_t_nsec is
in the Py_SAFE_DOWNCAST used to downcast an __int64 to int.
Py_SAFE_DOWNCAST checks that there is equality between the casted and
non-casted values with Py_DEBUG enabled--maybe in this function we
should remove Py_SAFE_DOWNCAST?

I can't find a way to see the actual value for "in" before the assert is
hit--I'm unfamiliar with picking through minidumps with WinDbg, which
for some reason will show me the stack for these dumps when Visual
Studio won't. But if I need to investigate more about them I can.

[amauryfa]

You almost gave the answer in your question - the FILE_TIME is about to be
converted to a time_t greater than 2**31.

in posixmodule.c::FILE_TIME_to_time_t_nsec(), a comment says:
/* XXX Win32 supports time stamps past 2038; we currently don't */
just before the assert()...

And indeed to reproduce the same crash it is enough to call os.stat() on a
file with a creation date in 2050 for example.

[amauryfa]

The attached patch corrects the problem: since VS2008 time_t is a 64bit
integer; now os.stat() can return times after 2038 on Windows.

This prevents the crash, but the functionality is far from complete:
os.utime() at least should accept 64bit times.

[loewis]

IIUC, the patch relies on VS 2008. So it is not a candidate for 2.5.3.

[vstinner]

Oh, this issue was already fixed by r87666 to fix the duplicate issue bpo-8278.

[vstinner]

Oh, this issue was already fixed by r87666

... in py3k, and then merged into release31-maint (r87668) and release27-maint (r87669).

[tiran]

New changeset 5151d64 by Christian Heimes in branch 'master':
bpo-4379: Skip TLS 1.0/1.1 tests under OpenSSL 3.0.0 (GH-25304)
5151d64

[miss-islington]

New changeset 4a5c101 by Miss Islington (bot) in branch '3.9':
bpo-4379: Skip TLS 1.0/1.1 tests under OpenSSL 3.0.0 (GH-25304)
4a5c101