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 failed on Windows buildbots
Type: crash Stage: resolved
Components: Library (Lib), Tests Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: Trundle, amaury.forgeotdarc, belopolsky, benjamin.peterson, brian.curtin, db3l, georg.brandl, loewis, pitrou, vstinner
Priority: critical Keywords:

Created on 2011-01-03 14:03 by pitrou, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (14)
msg125170 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-01-03 14:03
See e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.1

test_time
f:\dd\vctools\crt_bld\self_x86\crt\src\asctime.c(130) : Assertion failed: ( ( tb->tm_mday >= 1 ) && ( ( ( _days[ tb->tm_mon + 1 ] - _days[ tb->tm_mon ] ) >= tb->tm_mday ) || ( ( IS_LEAP_YEAR( tb->tm_year + 1900 ) ) && ( tb->tm_mon == 1 ) && ( tb->tm_mday <= 29 ) ) ) )
program finished with exit code -1073740777

(don't know about 2.6 but it's likely to crash there too)
msg125172 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-01-03 14:05
Regression introduced by r87648 (issue #8013).
msg125189 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 16:15
Can someone with a windows box test

>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 0, 0))?

If that crashes as well, can you tell which part of 

( ( tb->tm_mday >= 1 ) && ( ( ( _days[ tb->tm_mon + 1 ] - _days[ tb->tm_mon ] ) >= tb->tm_mday ) || ( ( IS_LEAP_YEAR( tb->tm_year + 1900 ) ) && ( tb->tm_mon == 1 ) && ( tb->tm_mday <= 29 ) ) ) )


triggers the assertion?
msg125192 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-01-03 16:26
Alexander:

>PCbuild\amd64\python_d.exe
Python 3.2b2+ (py3k, Jan  3 2011, 10:24:18) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
[54931 refs]
>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 0, 0))
'Mon Jan 01 00:00:00 <345'
[54935 refs]
msg125194 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 16:39
On Mon, Jan 3, 2011 at 11:26 AM, Brian Curtin <report@bugs.python.org> wrote:
..
>>PCbuild\amd64\python_d.exe
> Python 3.2b2+ (py3k, Jan  3 2011, 10:24:18) [MSC v.1500 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import time
> [54931 refs]
>>>> time.asctime((12345, 1, 1, 0, 0, 0, 0, 0, 0))
> 'Mon Jan 01 00:00:00 <345'

Thanks, Brian.  This is rather strange because checktm() is supposed
to convert tm_day=0 to 1:

    if (buf->tm_mday == 0)
        buf->tm_mday = 1;

Does time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0)) crash on your system?

BTW, '<' in the output looks like a naive ASCII encoding for the 12-th
millennium:

12

You may need year 300,000 to observe a crash.
msg125195 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-01-03 16:43
No crash on 0-day or 300,000. I bumped it up to 3,000,000 and got a UnicodeDecodeError, although I'm not sure of the relevance of that to this issue.


>>> time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0))
'Mon Jan 01 00:00:00 <345'
[54935 refs]
>>> time.asctime((300000, 1, 0, 0, 0, 0, 0, 0, 0))
'Mon Jan 01 00:00:00 \\000'
[54935 refs]
>>> time.asctime((3000000, 1, 0, 0, 0, 0, 0, 0, 0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe8 in position 20: invalid continuation byte
msg125196 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 16:56
On Mon, Jan 3, 2011 at 11:43 AM, Brian Curtin <report@bugs.python.org> wrote:
..
> No crash on 0-day or 300,000. I bumped it up to 3,000,000 and got a UnicodeDecodeError, although
> I'm not sure of the relevance of that to this issue.

It looks like we need an XP box with a debug version of the crt lib to
reproduce the crash.

..
>>>> time.asctime((3000000, 1, 0, 0, 0, 0, 0, 0, 0))
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> UnicodeDecodeError: 'utf8' codec can't decode byte 0xe8 in position 20: invalid continuation byte

Well, undefined behavior is undefined behavior.  Arguably, writing
binary garbage in a timestamp is better than crashing.  (given Windows
reputation, I would not be surprised if the above also involves
undetected memory corruption, though.) I am convinced that we don't
have a choice but to check the input of asctime() beforehand.  I am
preparing a patch.
msg125197 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-01-03 16:56
This is under 3.1, not 3.2.
msg125198 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-01-03 17:09
I can reproduce under Windows 7, 32-bit debug build, with the following line:

time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0))

Apparently, the debugger tells me that tb->tm_mday is 0.
Actually, most of the tb fields are 0 except tm_year (10445), tm_wday (1) and tm_yday (-1).

The code is the following:

    _VALIDATE_RETURN_ERRCODE(
        (
            ( tb->tm_mday >= 1 ) &&
            (
                // Day is in valid range for the month
                ( ( _days[ tb->tm_mon + 1 ] - _days[ tb->tm_mon ] ) >=
                        tb->tm_mday ) ||
                // Special case for Feb in a leap year
                (
                    ( IS_LEAP_YEAR( tb->tm_year + 1900 ) ) &&
                    ( tb->tm_mon == 1 ) &&
                    ( tb->tm_mday <= 29 )
                )
            )
        ),
        EINVAL
    )

So I would say the problem is really that the CRT should return EINVAL but instead triggers an assertion, perhaps because of a debug mode thing that we disable manually in 3.2?
msg125199 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 17:21
I committed a a fix for the test in r87690.  If this fixes the buildbot, I'll backport to 2.7 and call it a day for < 3.2.  For 3.2 a proper year range check will be added to close issue 8013.
msg125200 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2011-01-03 17:30
Btw, I have a failed assertion in the test suite, with "time.ctime(1e12)":
File: loctim64.c
Line: 78
Expression: (*ptime <= _MAX__TIME64_T)

This is a recent py3k, compiled with VS2005.
msg125203 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 17:41
On Mon, Jan 3, 2011 at 12:30 PM, Amaury Forgeot d'Arc
<report@bugs.python.org> wrote:
..
> Btw, I have a failed assertion in the test suite, with "time.ctime(1e12)"

This is from r87657.  I commented on that change in msg125117.
Hopefully a range check will fix that as well.
msg125208 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 18:00
The 3.1 buildbot is green:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.1/builds/1591

Committed 2.7 backport in r87692.
msg125214 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 19:00
2.7 buildbot is green as well.  Closing.

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.7
History
Date User Action Args
2022-04-11 14:57:10adminsetgithub: 55023
2011-01-03 19:00:39belopolskysetstatus: open -> closed
nosy: loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125214

resolution: fixed
stage: needs patch -> resolved
2011-01-03 18:00:09belopolskysetnosy: loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125208
2011-01-03 17:41:39belopolskysetnosy: loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125203
2011-01-03 17:30:29amaury.forgeotdarcsetnosy: loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125200
2011-01-03 17:21:58belopolskysetnosy: loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125199
2011-01-03 17:09:36pitrousetnosy: + loewis
messages: + msg125198
2011-01-03 16:56:53pitrousetnosy: georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125197
2011-01-03 16:56:35belopolskysetnosy: georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125196
2011-01-03 16:43:38brian.curtinsetnosy: georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125195
2011-01-03 16:39:40belopolskysetnosy: georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtin
messages: + msg125194
2011-01-03 16:26:24brian.curtinsetnosy: + brian.curtin
messages: + msg125192
2011-01-03 16:16:30Trundlesetnosy: + Trundle
2011-01-03 16:15:36belopolskysetnosy: georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson
messages: + msg125189
2011-01-03 15:41:11belopolskysetassignee: belopolsky
nosy: georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson
2011-01-03 14:05:22vstinnersetnosy: + vstinner
messages: + msg125172
2011-01-03 14:03:43pitroucreate