René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"sys.remote_exec() is unable to find writable memory when libpython got deleted/replaced on disk","articleBody":"# Bug report\n\n### Bug description:\n\n### The current happy path\n`sys.remote_exec()` looks at a remote PID's `/proc/\u003cpid\u003e/maps`, which allows it to find `libpython` on disk. Reading the `libpython` shared library file allows `sys.remote_exec()` to find the `.PyRuntime` section, which includes the debug offsets that point at the `remote_debugger_support.debugger_script_path[]` location where the debugger script path can be written to. The remote interpreter then finds the remotely injected update and does its thing to execute it.\n\n### The failure mode\nIn the case where `/proc/\u003cpid\u003e/maps` points at a libpython that got deleted from disk or replaced with a new file, this process fails early. CPython normally does not make any guarantees for such a case, but in this particular scenario we should be able to recover.\n\n### Why this is important to fix\nOn Linux in particular, in server environments scheduled package updates will include Python interpreter updates. When this happens, a long-running server process is now undebuggable. `sys.remote_exec()` is supposed to handle this very situation: allowing to debug a process without the need to kill it first.\n\nThe compatibility area between the `sys.remote_exec()` debugger and the debugged remote process is minimal: as long as both are the same minor version of Python (i.e. 3.14.x ←→ 3.14.x), the debug offsets structure will be parseable on both ends. ABI compatibility guarantees that no breaking changes for this use case will occur between bugfix releases within a minor release.\n\n### Suggested fix scope\nSince this is mostly important for centrally managed server scenarios, I suggest we address Linux first here and decide on other platforms after this succeeds.\n\nAs for the approach: even in the case of `/proc/\u003cpid\u003e/maps` pointing at a deleted file, it is also listing the memory location where that file was loaded. We can read the same information from memory then. Of course, file segments/sections are gone at this point, so it's a bit more of an involved process. But this will be a path taken only in the case when the file no longer exists on disk.\n\nAn alternative approach could be to try to dig out the inode of the now-deleted file and read the unlinked file that way. But this requires superuser privileges, so it's out of scope for `sys.remote_exec()`.\n\n### How to test this\nUsing `LD_LIBRARY_PATH=`, we can run a Python interpreter in such a way that it will pick up `libpython` from a copy in a temporary directory. Then the test will delete that copy, recreating our failure mode.\n\n### What about statically built Python?\nThis solution should also work for static builds. Instead of looking at `libpython`, we'd be looking at a deleted executable.\n\n### CPython versions tested on:\n\n3.14\n\n### Operating systems tested on:\n\nLinux\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-151032\n* gh-152443\n* gh-152464\n* gh-152653\n* gh-152665\n* gh-152669\n* gh-152670\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/ambv","@type":"Person","name":"ambv"},"datePublished":"2026-06-06T17:23:38.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/151029/cpython/issues/151029"}