-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
test_compileall fails in AMD64 Windows7 SP1 3.x #82651
Comments
This buildbot has been failing for a long time (example failure https://buildbot.python.org/all/#/builders/40/builds/3291) since 4267c98: ====================================================================== Traceback (most recent call last):
File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_py_compile.py", line 30, in wrapper
return fxn(*args, **kwargs)
File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_compileall.py", line 257, in test_compile_dir_maxlevels
self.assertTrue(os.path.isfile(self.bc_path_long))
AssertionError: False is not true ====================================================================== Traceback (most recent call last):
File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_py_compile.py", line 20, in wrapper
return fxn(*args, **kwargs)
File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_compileall.py", line 257, in test_compile_dir_maxlevels
self.assertTrue(os.path.isfile(self.bc_path_long))
AssertionError: False is not true Can someone try to fix the error, otherwise we would need to revert commit 4267c98. |
Oh! Sorry, I thought I saw green bots, and haven't looked since. |
If someone has access to Windows and can reproduce this (you need a more special setup than "just Windows"), and you want to spend some time debugging, please do. I'm shooting in the dark. My proposed patch limits the maximum path depth to 20 directories on Windows. That is enough to test compileall's maxlevels option. Still a longer path would be nicer if possible. |
You can trigger custom buildbot runs by pushing to the 'buildbot-custom' branch in the CPython repo. |
To reproduce the recent on a recent Windows 10, you can opt-out for long path using this change: diff --git a/PC/python.manifest b/PC/python.manifest
index 8e1bc022ad..524f9b2f6d 100644
--- a/PC/python.manifest
+++ b/PC/python.manifest
@@ -18,7 +18,6 @@
</compatibility>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
- <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
</windowsSettings>
</application>
<dependency> |
I'm okay with skipping the failing test if we detect sys.getwindowsversion().major < 10 Windows 7 is not supported for Python 3.9, so this buildbot can be disabled/upgraded. Windows 8.1 will be supported for at least 3.9, so we'll have to keep skipping the test there. |
As long as 3.7 and 3.8 are being tested through the buildbots, I would think testing on Windows 7 is still advised. That said, once those versions are no longer tested (or deemed to not need Windows 7 support) I will be upgrading that buildbot. |
I wrote PR 16789 which fix the issue. |
I tested in Windows 10 with long paths disabled, and the FileNotFoundError exception showed that the failing .pyc had a numeric suffix appended to the name. create_long_path isn't taking into account _write_atomic in Lib/importlib/_bootstrap_external.py. This function appends the id() of the target path string in order to create a temporary unique name, which it renames to the target if the write succeeds. Since the object ID is a memory address, create_long_path would need to append 16 characters to the longer_cache path. That's 1 for the initial "." of the suffix, plus 15 for the x64 address-space limit of 128 TB, i.e. len(str(0x7FFF_FFFF_FFFF)). Note that, by default, long-path support is not enabled in Windows 10. At process startup, the system runtime library enables long-path support if "LongPathsEnabled" is set in "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" and the application manifest enables "longPathAware". Both settings are required. For the buildbots, pythoninfo checks this as "windows.RtlAreLongPathsEnabled". According to this, for example, bolen-windows10 does not have long paths enabled. Yet test_compileall passed. bolen-windows10 It seems the test passed because the temp directory on this bot is relatively short: "D:\Temp". That's a factor because create_long_path adds directory components in blocks of 10. It uses 20 "dir_X_Y" components because 30 (240 characters) is too much for MAX_PATH no matter what. The same applies to the following buildbots for Windows 7 and 8.1: bolen-windows7 ware-win81-release On the other hand, kloth-win64 has a longer path for its temp directory: "C:\Users\Buildbot\AppData\Local\Temp". This costs an additional 29 characters compared to "D:\Temp" and brings the final path very close to MAX_PATH. The suffix appended by _write_atomic is typically 14-16 characters, which then exceeds MAX_PATH. |
Yeah, I found the same issue: I began to write a complex change to take _write_atomic() in account, but the test became super complex. I don't think that it's worth it. So I wrote a much simpler PR. Anyway, the issue should now be fixed. |
It seems like test_compileall now pass on the 4 Windows workers: |
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: