test_datetime fails with a --forever argument

[Eclips4]

Bug report

Bug description:

Output:

...many lines
test_resolution_info (test.datetimetester.TestTime_Fast.test_resolution_info) ... FAIL

======================================================================
FAIL: test_resolution_info (test.datetimetester.TestTime_Fast.test_resolution_info)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/admin/Projects/cpython/Lib/test/datetimetester.py", line 3685, in test_resolution_info
    self.assertIsInstance(self.theclass.max, self.theclass)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: -1224 is not an instance of <class 'datetime.time'>

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs

• gh-120782: Update internal type cache when reloading datetime #120829
• [3.13] gh-120782: Update internal type cache when reloading datetime (GH-120829) #120855
• gh-120782: Update datetime test for static type immutability #122800

[JelleZijlstra]

A more detailed repro case:

$ ./python.exe -m test test_datetime -v -m test_utctimetuple --forever
== CPython 3.14.0a0 (heads/fixsymtable:35f8855402a, Jun 19 2024, 22:18:17) [Clang 15.0.0 (clang-1500.3.9.4)]
== macOS-14.4.1-arm64-arm-64bit-Mach-O little-endian
== Python build: debug
== cwd: /Users/jelle/py/cpython/build/test_python_worker_88684æ
== CPU count: 8
== encodings: locale=UTF-8 FS=utf-8
== resources: all test resources are disabled, use -u option to unskip tests

Using random seed: 2286005019
0:00:00 load avg: 1.69 Run tests sequentially in a single process
0:00:00 load avg: 1.69 [  1] test_datetime
test_utctimetuple (test.datetimetester.TestDateTimeTZ_Pure.test_utctimetuple) ... ok
test_utctimetuple (test.datetimetester.TestDateTimeTZ_Fast.test_utctimetuple) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.001s

OK
0:00:00 load avg: 1.69 [  2] test_datetime
test_utctimetuple (test.datetimetester.TestDateTimeTZ_Pure.test_utctimetuple) ... ok
test_utctimetuple (test.datetimetester.TestDateTimeTZ_Fast.test_utctimetuple) ... ERROR

======================================================================
ERROR: test_utctimetuple (test.datetimetester.TestDateTimeTZ_Fast.test_utctimetuple)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jelle/py/cpython/Lib/test/datetimetester.py", line 4945, in test_utctimetuple
    dtz = d.replace(tzinfo=tz)
TypeError: tzinfo argument must be None or of a tzinfo subclass, not type 'datetime.timedelta'

----------------------------------------------------------------------
Ran 2 tests in 0.005s

FAILED (errors=1)
test test_datetime failed

== Tests result: FAILURE ==

1 test failed:
    test_datetime

1 test OK.

Total duration: 95 ms
Total tests: run=4 (filtered)
Total test files: run=2 (filtered) failed=1
Result: FAILURE

I added a print([timezone.min, timezone.utc, timezone.max]) right before the failure. It should output [datetime.timezone(datetime.timedelta(days=-1, seconds=60)), datetime.timezone.utc, datetime.timezone(datetime.timedelta(seconds=86340))], but I get various other things, apparently randomly:

• [datetime.timezone(datetime.timedelta(days=-1, seconds=60)), datetime.timezone.utc, 9999]
• [datetime.timedelta(seconds=86340), datetime.timezone.utc, 9999]
• [datetime.timedelta(seconds=86340), datetime.timezone.utc, datetime.timezone(datetime.timedelta(seconds=86340))]

This suggests the timezone class's __dict__ is somehow getting corrupted.

[JelleZijlstra]

The failure goes away with this diff, which disables the type cache:

diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index 1cc6ca79298..4e4b3f79121 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -5437,7 +5437,7 @@ _PyType_LookupRef(PyTypeObject *type, PyObject *name)
     }
 #else
     if (entry->version == type->tp_version_tag &&
-        entry->name == name) {
+        entry->name == name && 0) {
         assert(type->tp_version_tag);
         OBJECT_STAT_INC_COND(type_cache_hits, !is_dunder_name(name));
         OBJECT_STAT_INC_COND(type_cache_dunder_hits, is_dunder_name(name));

So this is related to the type cache.

[Eclips4]

Bisected to 3e8b609
cc @erlend-aasland

[neonene]

The fix is now superseded by

• GH-121832: Assert that the version number of static builtin types is not changed by PyType_Modified. #122182

See also #122184.