This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Assertion failures in datetimemodule.c.
Type: crash Stage: resolved
Components: Interpreter Core Versions: Python 3.8, Python 3.7, Python 3.6, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: gregory.p.smith, miss-islington, ned.deily, serhiy.storchaka, twouters
Priority: high Keywords: 3.6regression, 3.7regression, patch

Created on 2018-10-18 17:37 by twouters, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 9958 closed serhiy.storchaka, 2018-10-18 21:12
PR 10039 merged serhiy.storchaka, 2018-10-22 19:54
PR 10040 closed serhiy.storchaka, 2018-10-22 20:09
PR 10614 merged miss-islington, 2018-11-20 18:41
PR 10615 merged miss-islington, 2018-11-20 18:41
PR 10617 merged serhiy.storchaka, 2018-11-20 19:15
Messages (8)
msg327989 - (view) Author: Thomas Wouters (twouters) * (Python committer) Date: 2018-10-18 17:37
The fix for issue #31752 (changeset 5ef883b096895a84123760859f0f34ad37bf2277 for 2.7, as I ran into this while upgrading to 2.7.15) includes assertions that are easily triggered from user code:

>>> import datetime, numpy
>>> datetime.timedelta(seconds=numpy.int64(0))
python: .../Modules/datetimemodule.c:1859: accum: Assertion `_PyAnyInt_CheckExact(prod)' failed.
Aborted (core dumped)

The code asserts that the product of a known type and an unknown type is a known type, which is not a valid assumption. Pure-python reproducer (requires a build with assertions enabled, like a --with-pydebug build).

>>> import datetime
>>> class C(int):
...     def __rmul__(self, other):
...         return self
...
>>> datetime.timedelta(seconds=C())
python: .../Modules/datetimemodule.c:1859: accum: Assertion `_PyAnyInt_CheckExact(prod)' failed.
Aborted (core dumped)

(It fails in a similar way in at least Python 3.7, and since the fix was backported I'm going to assume 3.6 as well.)

Please do not use assertions for things that aren't guaranteed by the code making the assertions. These should either not be assertions, or the input types should be validated beforehand. I do not know why these assertions are being made in the first place. What do they guard against?
msg327993 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-10-18 18:01
Mia culpa! I missed that the type of the right operand takes precedence when it is a subclass of the type of the left operand.
msg330142 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-11-20 18:41
New changeset 3ec0f495163da3b7a15deb2805cec48aed432f58 by Serhiy Storchaka in branch 'master':
bpo-35021: Fix assertion failures in _datetimemodule.c. (GH-10039)
https://github.com/python/cpython/commit/3ec0f495163da3b7a15deb2805cec48aed432f58
msg330145 - (view) Author: miss-islington (miss-islington) Date: 2018-11-20 18:59
New changeset d57ab8ac182d15558118523ad1b11b029e105c46 by Miss Islington (bot) in branch '3.7':
bpo-35021: Fix assertion failures in _datetimemodule.c. (GH-10039)
https://github.com/python/cpython/commit/d57ab8ac182d15558118523ad1b11b029e105c46
msg330147 - (view) Author: miss-islington (miss-islington) Date: 2018-11-20 19:02
New changeset 7a0d964afb41bde846771c81ba746238339cdd8c by Miss Islington (bot) in branch '3.6':
bpo-35021: Fix assertion failures in _datetimemodule.c. (GH-10039)
https://github.com/python/cpython/commit/7a0d964afb41bde846771c81ba746238339cdd8c
msg330150 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-11-20 19:56
New changeset 40fdf471931f029ea07e6190f0fe116e0735661b by Serhiy Storchaka in branch '2.7':
[2.7] bpo-35021: Fix assertion failures in _datetimemodule.c. (GH-10039) (GH-10617)
https://github.com/python/cpython/commit/40fdf471931f029ea07e6190f0fe116e0735661b
msg345801 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-06-17 07:22
Can we close this or is there anything further needed for this issue?
msg347625 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-07-10 15:37
Assuming answer to previous question is "no" -> closing
History
Date User Action Args
2022-04-11 14:59:07adminsetgithub: 79202
2019-07-10 15:37:04ned.deilysetstatus: open -> closed
resolution: fixed
messages: + msg347625

stage: patch review -> resolved
2019-06-17 07:22:45ned.deilysetnosy: + ned.deily
messages: + msg345801
2018-11-20 19:56:41serhiy.storchakasetmessages: + msg330150
2018-11-20 19:15:48serhiy.storchakasetpull_requests: + pull_request9863
2018-11-20 19:02:52miss-islingtonsetmessages: + msg330147
2018-11-20 18:59:14miss-islingtonsetnosy: + miss-islington
messages: + msg330145
2018-11-20 18:41:38miss-islingtonsetpull_requests: + pull_request9860
2018-11-20 18:41:32miss-islingtonsetpull_requests: + pull_request9858
2018-11-20 18:41:12serhiy.storchakasetmessages: + msg330142
2018-10-22 20:09:05serhiy.storchakasetpull_requests: + pull_request9378
2018-10-22 19:54:58serhiy.storchakasetpull_requests: + pull_request9376
2018-10-18 21:12:09serhiy.storchakasetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request9305
2018-10-18 18:01:06serhiy.storchakasetmessages: + msg327993
2018-10-18 17:37:14twouterscreate