-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build problems on Windows #91193
Comments
3.11 apparently builds without error, and 'python' and 'python -m idlelib' appears to start normally, but there is a new problem. 3.10 and 3.9 (but not 3.11): compiling show a newish warning. Does not 3.11 also require this? (wherever it is supposed to be?). Aside from the warning, 3.10 appear to be working normally. There is no error box when starting tests and 50 have run so far without a box. |
This sounds more like recent installation changes on your machine. Have I'm not aware of any recent compilation changes that would cause this. |
Actually, I see this ('Debug Assertion Failed!' in the same spot) every time I try to run the test suite with a debug build, starting yesterday. Didn't have time to track it down. It _appeared_ to an obscure consequence of this commit: """
""" |
BTW, the frequency of this new failure mode appears to be vastly increased if running the debug tests with "-j0". For example, the box popping up is reliably the very first sign of life if I run this from the PCBuild directory: rt -q -d -j0 |
bpo-46587 added top-level code to "Lib/test/support/init.py" to check whether time.strftime("%4Y") works. Since "Lib/test/libregrtest/setup.py" imports the support module, that code executes before suppress_msvcrt_asserts() is called by setup_tests(). |
indeed, bisected to 2cf7f86 is the first bad commit
|
Ouch, is Python crashes because of an unsupported strftime call? |
Christian, yes, but only in a debug build. See Eryk Sun's message a bit above: the machinery to prevent this is already present, but isn't getting called early enough. |
Re the 3.9/3.10 warnings: I have not intentionally touched my C install in years. I don't know what Windows' updates do (most recently yesterday) . I presume vcruntime140.dll is on my C: ssd, which has shown no problems. Debug runs w/o -j0 normally take about 18 minutes. After 51 minutes, the 3.10 test run froze CP (as in, had to close with [X] and reopen). Output ends with "0:51:02 load avg: 0.01 [407/427] test_winconsoleio Ä^Z" |
It's not a crash. It's a CRT error report dialog, which is enabled by default for the _CRT_ASSERT and _CRT_ERROR macros in debug builds. This dialog can be helpful when debugging interactively. It gives a developer the option to abort, retry, or ignore. If a debugger is attached, the retry option breaks into the debugger. I attached a debugger to the test runner to diagnose the problem with format code "%4Y". For example: >>> time.strftime('%4Y')
Debug Assertion Failed!
[...]
(Press Retry to debug the application)
(1a6c.101c): Break instruction exception - code 80000003 (first chance)
ucrtbased!_Wcsftime_l+0x5af:
00007ff8`a582b9af cc int 3 backtrace:
locals:
resume, with the STATUS_BREAKPOINT (0x80000003) exception handled: 0:000> gh
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid format string
>>> For non-interactive testing the report mode needs to be configured to 0 (no report) or to report to stderr. For example: >>> msvcrt.CrtSetReportMode(msvcrt.CRT_ERROR, msvcrt.CRTDBG_MODE_FILE)
4
>>> msvcrt.CrtSetReportFile(msvcrt.CRT_ERROR, msvcrt.CRTDBG_FILE_STDERR)
18446744073709551615
>>> os.abort()
abort() has been called For time.strftime('%4Y'), the source of the report is _VALIDATE_RETURN(false, EINVAL, 0) in _Wcsftime_l(). This macro includes an _ASSERT_EXPR(expr, msg) check. In a debug build, this calls _CrtDbgReportW(_CRT_ASSERT, ...) if the expression is false. If the latter returns 1 (retry), the __debugbreak() intrinsic is called to break into the debugger. To suppress the dialog, either temporarily set the CRT_ASSERT report mode to 0, or set it to report to stderr. For example: >>> msvcrt.CrtSetReportMode(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_MODE_FILE)
4
>>> msvcrt.CrtSetReportFile(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_FILE_STDERR)
18446744073709551615
>>> time.strftime('%4Y')
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1163) : Assertion failed: false
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid format string |
I think this is also a good enough reason to switch the GitHub CI back to a debug build, rather than release, so that assert failures are caught before they get merged. This is not the first time it's happened. |
I recompiled, retested, and all tests are ok, with no unexpected box. Thank you all. The vcruntime warnings are also gone, so I will chalk them up to a onetime glitch. |
The main entry point for python[_d].exe should support a command-line -X option or environment variable that suppresses Windows error/assert/warn reporting, or redirects it to stderr in verbose mode. This would be useful to simplify everyone's automated testing. It should require opting in, both for backward compatibility and also because the dialogs are useful for interactive testing. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: