-
-
Notifications
You must be signed in to change notification settings - Fork 31.5k
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
gh-131591: Implement PEP 768 #131592
gh-131591: Implement PEP 768 #131592
Conversation
pablogsal
commented
Mar 22, 2025
•
edited by bedevere-app
bot
Loading
edited by bedevere-app
bot
- Issue: Implement PEP 768 – Safe external debugger interface for CPython #131591
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial observations (I've looked at everything but the interesting stuff, haven't gotten to Python/remote_debugging.c or Lib/test/test_sys.py yet)
The PyRuntime section can be found in either the main executable (python.exe) or the Python DLL (pythonXY.dll, where X and Y represent the major and minor version numbers). Scan the modules of the process to locate the PyRuntime address in one of these modules.
Ensure that the caller and target processes have matching architectures before proceeding. Attaching to a 64-bit process from a 32-bit process will fail when using CreateToolhelp32Snapshot, and attempting to attach to a 32-bit process from a 64-bit process may cause issues during PE file parsing. To avoid potential errors abort the operation if the architectures differ.
This reverts commit 746ecfc. That commit isn't correct. It conflates the return from `IsWow64Process` (whether the process is running under 32-bit emulation on a 64-bit process) with whether the process is 64-bit. A 32-bit process on 32-bit Windows would have `IsWow64Process` set our `isWow64` flag to `FALSE`, and we'd then incorrectly return `TRUE` from `is_process64Bit`.
…_support External debugger Windows support
This is useful because debuggers will write to this variable remotely, and it's helpful for it to have a well known size rather than one that could vary per platform.
Require the flags for turning this on to be set to exactly 1 to avoid accidentally triggering remote debugging in the case of heap corruption. Make a heap copy of the script path before using it to avoid the buffer being overwritten while we're still using it by another debugger.
This avoids the need to reopen it by (wide character) path.
Previously it was leaked if `PyObject_AsFileDescriptor` failed.
I think this was a copy paste error.
The remote process must be a compatible version. Explain our compatibility rules.
We can clean this up by freeing strings as soon as we're done with them, and remove some duplicate code.
This was documented as working, but in fact we assumed that the path would always be a unicode string. Factor the version that only accepts a unicode string into a helper function, and have the caller call `os.fsdecode` on the input path, which accepts either a byte string or a unicode string and always returns a unicode string.
Previously we were returning the number of bytes, which we didn't need and would never be different than the argument that was passed into the function.
This field in the structure is defined as an `unsigned long`, not as a `pid_t`.
We already did a `strlen` on the `debugger_script_path`, so it's too late to check if it's NULL here!
This helps to harden a bit against heap corruption.
🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 80856d3 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F131592%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
I'm going to close this and reopen because the CI got stuck somehow |