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)

Regression introduced by r87648 (issue #8013).

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?

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]

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.

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

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.

This is under 3.1, not 3.2.

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?

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.

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.

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.

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.

2.7 buildbot is green as well.  Closing.

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