Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This investigates the Windows blocking-sampler failures reported in python#158552. Two Windows 2025/VS 2026 runners build Python 3.15.0rc1 and compare live sampling, suspension, suspension plus a delay, and suspension plus GetThreadContext. They repeat the measurements with the existing fix from python#157817 applied. Each workload runs with frame caching enabled and disabled.
The first run reproduced blocking failures with a callback invoked through map() while a large local list is freed. On the Xeon Platinum 8573C, 1,394/3,000 blocking samples failed (46.47%); on the Xeon Platinum 8370C, 1,463/3,000 failed (48.77%). Adding GetThreadContext left failure rates at 47.43% and 49.67%. Applying the existing parser fix reduced blocking failures to 0/3,000 on both runners. The results also held with frame caching disabled. Short-call and direct-call controls had no blocking failures.
These results confirm a Windows failure mechanism involving an interpreter entry frame during callback cleanup. Neither runner has the reporter's EPYC 9V45 CPU, and the original workload is not available, so this does not establish the cause of the reported CPU difference. Complete logs and hardware details are attached to https://github.com/pablogsal/cpython/actions/runs/36892178672.
Both runners completed the measurements. I cancelled the remaining SSH setup after the original tmate relay failed to produce a connection address. A separate SSH session started successfully using the WarpBuild relay: https://github.com/pablogsal/cpython/actions/runs/36894579541. Access requires one of the triggering user's GitHub SSH keys; the connection command is in the run summary and the windows-158552-ssh artifact. It waits 15 minutes for a connection, with a 45-minute job limit.
The workflow can be dispatched with ssh_only=true to open one fresh runner with the rc1 sources, skipping builds and measurements. It passes actionlint and the repository's workflow lint checks. This draft uses a temporary base branch to keep the investigation separate from the normal CPython test matrix. It is not intended to merge.