Repository navigation
PR check "Check if generated files are up to date" failing intermittently #91302
Description
Activity
ericsnowcurrently commented
on Mar 28, 2022 MemberAuthorMore actionsThe "Check if generated files are up to date" GitHub check for PRs has been failing recently. It may also impact local usage of "make regen-all".
Example: https://github.com/python/cpython/runs/5719012664
This may be related to #76242.
- addedbuildThe build process and cross-buildThe build process and cross-build3.11only security fixesonly security fixes
on Mar 28, 2022 - addedbuildThe build process and cross-buildThe build process and cross-build
on Mar 28, 2022 ericsnowcurrently commented
on Mar 28, 2022 MemberAuthorMore actionsThere's probably something racy with make.
See: https://github.com/python/cpython/runs/5712538599?check_suite_focus=true#step:10:1147
ericsnowcurrently commented
on Mar 28, 2022 MemberAuthorMore actionsericsnowcurrently commented
on Mar 28, 2022 MemberAuthorMore actionsLooks like that fixed it, per #32134.
ericsnowcurrently commented
on Mar 30, 2022 MemberAuthorMore actionsLooks like this is still an intermittent problem:
- bpo-47168: Mark files generated by
make regen-limited-abias generated #32195
+ failed: https://github.com/python/cpython/runs/5756616733
+ failed: https://github.com/python/cpython/runs/5753267869
+ failed: https://github.com/python/cpython/runs/5757169625 - bpo-40421: Add missing getters for frame object attributes to C-API. #32114
+ failed: https://github.com/python/cpython/runs/5756616733
+ passed: https://github.com/python/cpython/runs/5757213346 - bpo-47151: Fallback to fork when vfork fails in subprocess. #32186
+ failed: ...
+ passed: https://github.com/python/cpython/runs/5757178754
Per Mark Shannon (on discord):
The "Check if generated files are up to date" is still failing consistently. It looks like the makefile is missing a dependency on the ./Programs/_freeze_module for targets that require /Programs/_freeze_module
- bpo-47168: Mark files generated by
The problem is likely a recursive make call "$(MAKE)" in combination with parallel execution. As far as I understand it, GNU make cannot track dependencies properly, which can lead to partial or invalid dependency graphs. One make process can modify a file while another uses the file. The permission error or ETXTBSY error are manifestation of one process creating an executable while another process is attempting to execve() it.
The paper https://accu.org/journals/overload/14/71/miller_2004/ explains the issues with recursion in great detail.
ericsnowcurrently commented
on Mar 31, 2022 MemberAuthorMore actionsericsnowcurrently commented
on Mar 31, 2022 MemberAuthorMore actionsI re-ran jobs that had failed before I merged that #76387. Several passed, but the following are still failing:
- [WIP] bpo-23689: re module, fix memory leak when a match is terminated by a signal #32188
+ https://github.com/python/cpython/runs/5773938424 - bpo-47131: Speedup AST comparisons in test_unparse by using node traversal #32132
+ https://github.com/python/cpython/runs/5774054192 - bpo-47152: Convert the re module into a package #32177
+ https://github.com/python/cpython/runs/5773949869
Back to the drawing board...
- [WIP] bpo-23689: re module, fix memory leak when a match is terminated by a signal #32188
ericsnowcurrently commented
on Mar 31, 2022 MemberAuthorMore actionsBrandt pointed out this is consistently reproducible locally:
make clean regen-all -j
I'll get this sorted out today.
ericsnowcurrently commented
on Mar 31, 2022 MemberAuthorMore actionsericsnowcurrently commented
on Mar 31, 2022 MemberAuthorMore actionsI'll keep an eye on PRs for the next day or so.
ericsnowcurrently commented
on Mar 31, 2022 MemberAuthorMore actionsLooks like #76399 worked.
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: