| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
LGTm thanks for the pr! |
Sorry, something went wrong.
|
Thanks @zainnadeem786 for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15. |
Sorry, something went wrong.
|
GH-152512 is a backport of this pull request to the 3.15 branch. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Summary
Fixes gh-152356.
On Windows, profiling.sampling run --blocking could hang indefinitely after the target process had already exited, leaving an empty binary profile that could not be replayed.
The non-blocking sampling path already terminates correctly when the target exits, but the Windows blocking implementation classified the same process-exit condition differently.
Root Cause
During blocking sampling, the profiler pauses the target through the Windows remote debugging layer.
If the target process has already exited, NtSuspendProcess() fails. The Windows implementation currently reports this as a RuntimeError.
The sampling loop treats RuntimeError as a recoverable sampling failure and continues retrying, so profiling never finishes and the binary profile writer is never finalized.
Other platforms already report terminated processes as ProcessLookupError, which the sampling loop correctly treats as a terminal condition.
Changes
This patch updates the Windows implementation of _Py_RemoteDebug_StopAllThreads().
When NtSuspendProcess() fails because the target process has already terminated, the remote debugging layer now raises ProcessLookupError instead of RuntimeError.
Existing RuntimeError behaviour is preserved for genuine NtSuspendProcess() failures while alive processes are unaffected.
No other profiling behaviour changes.
Tests
Added a Windows-only regression test that:
Validation
Validated with:
After this change, Windows blocking sampling terminates correctly once the target process exits and produces a valid replayable binary profile.