Issue 10814: assertion failed on Windows buildbots (original) (raw)

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 "", line 1, in 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 "", line 1, in > 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 . 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:10 admin set github: 55023
2011-01-03 19:00:39 belopolsky set status: open -> closednosy:loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: + resolution: fixedstage: needs patch -> resolved
2011-01-03 18:00:09 belopolsky set nosy:loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: +
2011-01-03 17:41:39 belopolsky set nosy:loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: +
2011-01-03 17:30:29 amaury.forgeotdarc set nosy:loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: +
2011-01-03 17:21:58 belopolsky set nosy:loewis, georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: +
2011-01-03 17:09:36 pitrou set nosy: + loewismessages: +
2011-01-03 16:56:53 pitrou set nosy:georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: +
2011-01-03 16:56:35 belopolsky set nosy:georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: +
2011-01-03 16:43:38 brian.curtin set nosy:georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: +
2011-01-03 16:39:40 belopolsky set nosy:georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson, Trundle, brian.curtinmessages: +
2011-01-03 16:26:24 brian.curtin set nosy: + brian.curtinmessages: +
2011-01-03 16:16:30 Trundle set nosy: + Trundle
2011-01-03 16:15:36 belopolsky set nosy:georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.petersonmessages: +
2011-01-03 15:41:11 belopolsky set assignee: belopolskynosy:georg.brandl, db3l, amaury.forgeotdarc, belopolsky, pitrou, vstinner, benjamin.peterson
2011-01-03 14:05:22 vstinner set nosy: + vstinnermessages: +
2011-01-03 14:03:43 pitrou create