线上 Python 服务卡住、CPU 飙高，或者某个数据任务跑了几个小时以后开始变慢时，重启往往是最后手段。进程里的现场还在：线程停在哪一层调用栈，哪些对象还活着，哪个函数正在反复分配内存。进程一停，这些信息也就没了。

这时自然会想：能不能趁这个 PID 还活着，把一小段诊断逻辑送进去，让它在原来的 Python 解释器里执行？这就是进程注入，也常叫 process attach。它不是为了给业务代码增加新功能，而是让外部工具临时进入目标进程，读取运行时状态、安装 hook，或者启动一个诊断 agent。

pyrasite、memray、peeka 都依赖这类能力，只是进入目标进程的方式越来越谨慎。接下来按三代方案展开：GDB 直接调用 C API、dlopen + pthread、以及 Python 3.14 之后的 PEP 768。

1. 进程注入的本质问题

要理解进程注入，先要理解我们面临的约束：

• 地址空间隔离：每个进程有独立的虚拟地址空间，A 进程无法直接读写 B 进程的内存
• GIL（全局解释器锁）：Python 的 C API 调用几乎都需要持有 GIL
• 执行时机：目标进程可能正处于任何状态——malloc 中途、GC 扫描中、持有 import 锁……

工程上可以拆成三个子问题：

1. 进入目标进程的地址空间（跨进程控制）
2. 在目标解释器里安全执行 Python 代码（GIL 获取）
3. 选择足够安全的执行时机（时机选择）

不同的工具对这三个问题给出了不同的答案。

2. 第一代：pyrasite 与 GDB 直接调用 C API

pyrasite（2011 年）是最早的 Python 进程注入工具之一。它的方案简单直接：

原理

利用 ptrace 系统调用暂停目标进程，然后通过 GDB 直接调用 Python 的 C API 执行任意 Python 代码。

核心代码

pyrasite 的核心注入路径很短：

# 执行位置：pyrasite 控制端进程；Popen 会启动一个 GDB 子进程
# pyrasite/injector.py（简化）
gdb_cmds = [
    'call (int) PyGILState_Ensure()',
    'call (int) PyRun_SimpleString("exec(open(\\'%s\\').read())")' % filename,
    'call (void) PyGILState_Release($1)',
]
subprocess.Popen(
    'gdb -p %d -batch %s' % (pid, ' '.join(
        ["-eval-command='call %s'" % cmd for cmd in gdb_cmds]
    )),
    shell=True
)

即：

1. pyrasite 控制端进程通过 subprocess.Popen(...) 启动一个 GDB 子进程
2. GDB 子进程通过 ptrace(PTRACE_ATTACH) 暂停目标进程
3. GDB 子进程在暂停点让目标进程调用 PyGILState_Ensure() 获取 GIL
4. GDB 子进程让目标进程调用 PyRun_SimpleString() 执行一段 Python 代码
5. GDB 子进程让目标进程调用 PyGILState_Release() 释放 GIL
6. GDB detach，目标进程恢复执行

ptrace 的角色

ptrace 是 Linux 内核提供的进程调试接口。GDB、strace、lldb 的底层都依赖它。

调试器进程                    目标进程
    │                           │
    │── ptrace(ATTACH, pid) ───>│  暂停目标
    │                           │  (SIGSTOP)
    │── ptrace(PEEKTEXT) ──────>│  读内存
    │── ptrace(POKETEXT) ──────>│  写内存
    │── ptrace(GETREGS) ───────>│  读寄存器
    │── ptrace(SETREGS) ───────>│  改寄存器 -> 修改执行流
    │── ptrace(CONT) ──────────>│  恢复执行
    │── ptrace(DETACH) ────────>│  脱离

GDB 正是利用 ptrace 的能力，在目标进程的上下文中"调用"C 函数。具体来说，GDB 每执行一条 call 命令，都会经历以下 6 步：

1. 保存目标进程当前的寄存器状态
2. 将函数参数写入寄存器/栈（遵循 ABI 调用约定）
3. 将指令指针（rip）设为目标函数地址
4. 设置断点用于在函数返回后接管控制
5. 恢复执行
6. 函数执行完毕后，GDB 命中断点，恢复原始寄存器

因此，pyrasite 的三条 GDB 命令（call PyGILState_Ensure()、call PyRun_SimpleString(...)、call PyGILState_Release($1)）各自独立地经历这 6 步。每次 call 都是一次完整的"保存->篡改->执行->恢复"循环。

随机暂停点的风险

问题出在时机上。当 GDB attach 并暂停目标进程时，目标可能正处于任何状态：

目标进程的执行时间线：
... -> malloc() -> [GDB 在这里暂停] -> PyGILState_Ensure() -> 💥

问题：malloc 内部持有 heap lock
      PyRun_SimpleString 可能也要调 malloc
      -> 死锁

更具体地说：

pyrasite 本质上是在"碰运气"——大多数时候目标进程不在这些危险状态，所以注入成功。但在生产环境中，这种不确定性是不可接受的。

3. 第二代：memray/peeka 的 dlopen + pthread 方案

memray（Bloomberg 开源的内存分析器）和 peeka 在 Python 3.8-3.13 上采用了相似的改进方案。核心思路是：GDB/LLDB 不直接在 ptrace 暂停点执行 Python 代码；它先注入一个 C 扩展，再由 C 扩展在更可控的时机执行代码。

原理概览

peeka/memray 控制端          GDB/LLDB 子进程              目标 Python 进程
    │                            │                              │
    │  3.1：bind/listen 本地端口  │                              │
    │-- 启动 GDB/LLDB ---------->│                              │  3.1：传入端口和注入库路径
    │                            │-- ptrace ATTACH ------------>│  暂停
    │                            │-- 等待安全断点命中 ----------->│  3.2：malloc/PyMem_* 等 C 函数入口
    │                            │                              │
    │                            │-- dlopen("_inject.so") ----->│  3.3：加载 C 扩展到目标地址空间
    │                            │-- call peeka_spawn_agent() ->│  3.4：创建新 pthread
    │                            │-- ptrace DETACH ------------>│  恢复执行
    │                            │                              │
    │<---------------------------┼------------------------------│  3.5：[新 pthread] connect() 回连 + 接收脚本
    │                            │                              │  ├- PyGILState_Ensure()
    │                            │                              │  ├- PyEval_EvalCode()
    │                            │                              │  └- PyGILState_Release()

在这条路径里，确实会短暂存在三个进程：用户启动的 peeka/memray 控制端进程、控制端临时启动的 GDB/LLDB 子进程、被 attach 的目标 Python 进程。GDB/LLDB 子进程只负责 ptrace、dlopen 和调用 peeka_spawn_agent(port)；agent 代码的传输发生在控制端进程和目标进程中新建的 pthread 之间。

后面按五个关键环节展开：控制端准备、安全断点、dlopen 注入、独立线程、反向连接传输。

3.1 控制端准备——监听端口与启动调试器

在 GDB/LLDB 进入目标进程之前，peeka/memray 控制端会先准备一个本地 TCP server。这个端口的作用很单一：等目标进程中新建的 agent 线程回连，然后把完整的 agent 脚本传过去。

以 peeka 的 GDB 路径为例，控制端大致会做两件事：先 bind/listen 一个本地端口，再启动 GDB 子进程并把端口号、注入库路径传给它。

# 执行位置：peeka/memray 控制端进程；省略错误处理和部分准备逻辑
def _create_notify_server(self) -> int:
    self._notify_server = sock_mod.socket(sock_mod.AF_INET, sock_mod.SOCK_STREAM)
    self._notify_server.setsockopt(sock_mod.SOL_SOCKET, sock_mod.SO_REUSEADDR, 1)
    self._notify_server.bind(("127.0.0.1", 0))
    self._notify_server.listen(1)
    return self._notify_server.getsockname()[1]

notify_port = self._create_notify_server()
injector_path = _find_injector_path()
gdb_script = os.path.join(os.path.dirname(__file__), "_attach.gdb")

cmd = ["gdb", "-p", str(self.pid), "-batch", "-q"]
cmd.extend(["-eval-command", f"set $peeka_port = {notify_port}"])
cmd.extend(["-eval-command", f'set $peeka_injector = "{injector_path}"'])
cmd.extend(["-eval-command", f"set $peeka_rtld_now = {_RTLD_NOW}"])
cmd.extend(["-x", gdb_script])

subprocess.run(cmd, ...)

这段代码运行在控制端进程里；它启动一个 GDB 子进程，并把三个变量传给 GDB：

• $peeka_port：目标进程中新线程回连控制端时使用的 TCP 端口
• $peeka_injector：要 dlopen 的 _inject.so 路径
• $peeka_rtld_now：传给 dlopen 的 RTLD_NOW

3.2 安全断点——选择正确的时机

pyrasite 在任意位置暂停后就执行 C API；memray/peeka 会等到更明确的 C 函数边界再注入。

真正的断点设置和 dlopen 调用写在 _attach.gdb 里：

# 执行位置：GDB 进程；call 命令会让目标进程在自身上下文中执行对应 C 函数
# peeka/core/_attach.gdb
call (int)Py_AddPendingCall(&PyCallable_Check, (void*)0)

b malloc
b calloc
b realloc
b free
b PyMem_Malloc
b PyMem_Calloc
b PyMem_Realloc
b PyMem_Free
b PyErr_CheckSignals
b PyCallable_Check

commands 1-10
    disable breakpoints
    delete breakpoints
    call (void*)dlopen($peeka_injector, $peeka_rtld_now)
    call (int)peeka_spawn_agent($peeka_port)
end

continue

这段脚本做的事情可以拆成两部分看：

1）安排一次将来会发生的 CPython 回调。

Py_AddPendingCall(&PyCallable_Check, 0) 会把 PyCallable_Check 放进 pending-call 队列，等待 CPython eval loop 在下一个检查点调用它。这个安排用于覆盖一种常见情况：目标进程正在跑纯 Python tight loop，短时间内不触发新的 malloc 或 PyMem_Malloc。b PyCallable_Check 在最终 continue 之前设好后，pending call 触发时就能命中断点。因此源码里把 Py_AddPendingCall 放在 b malloc 之前并不矛盾。

2）把注入动作挂到一组 C 函数入口断点上。

2.1）先设置断点。脚本在 malloc、PyMem_Malloc、PyCallable_Check 等函数上打断点。这里的"函数入口"指 GDB 断点列出的 C 函数入口；用户代码里 def foo(): ... 的 Python 函数入口属于另一个层面。例如：

• malloc、calloc、free 是 libc allocator 的函数入口
• PyMem_Malloc、PyMem_Free 是 CPython 内存分配 API 的函数入口
• PyErr_CheckSignals、PyCallable_Check 是 CPython 运行时中的普通 C API 函数入口

PyMem_Malloc 和 malloc 覆盖的是不同层。PyMem_Malloc 是 CPython 的分配 API，底层可能走 pymalloc，也可能在需要新 arena、大块分配、PYTHONMALLOC=malloc 或自定义 allocator 时进一步走系统 malloc。同时设置 PyMem_* 和 malloc/free 断点，可以覆盖 CPython 分配层和 libc 分配层这两个边界。

2.2）再绑定命中后的动作。commands 1-10 给这些断点绑定同一组命令：一旦任意断点命中，就调用 dlopen(...) 加载注入库，再调用 peeka_spawn_agent(...) 创建 agent 线程。

命中后先 disable breakpoints / delete breakpoints 也很重要。dlopen 本身可能触发动态链接、符号解析和内存分配，如果断点还留着，注入过程可能再次撞上 malloc/free 断点，导致流程变得不可控。

断点命中时，GDB 停在某个函数的入口处：以 malloc 为例，此时命中的线程还没进入 allocator 内部临界区，也还没有修改堆结构。这比 pyrasite 在随机暂停点直接调用 Python C API 可控得多。严格说，它没有证明整个进程绝对安全；它把注入时机从"任意机器指令位置"收敛到"已知 C 函数边界"。

3.3 dlopen——将 C 扩展加载到目标进程

dlopen 是 POSIX 系统的动态链接器接口。通过 GDB 在目标进程中调用 dlopen("_inject.abi3.so", RTLD_NOW)，我们将一个编译好的 C 扩展加载到目标进程的地址空间中。

这比 PyRun_SimpleString 强大的关键在于：C 代码可以创建线程，可以操作底层系统资源，不受 GIL 约束。

peeka 在 macOS 上使用 LLDB 完成相同的工作：

# 执行位置：LLDB 进程；expr/p 命令会让目标进程在自身上下文中执行对应 C 函数
# peeka/core/_attach.lldb
expr auto $dlsym = (void* (*)(void*, const char*))&::dlsym
expr auto $dlopen = $dlsym($rtld_default, "dlopen")
expr auto $dll = ((void*(*)(const char*, int))$dlopen)($libpath, $rtld_now)
expr auto $spawn = $dlsym($dll, "peeka_spawn_agent")
p ((int(*)(int))$spawn)($port) ? "FAILURE" : "SUCCESS"

3.4 独立线程——解耦注入与执行

dlopen 之后，GDB 调用 C 扩展的 peeka_spawn_agent() 函数。这个函数的工作很少：

// 执行位置：目标进程；该函数来自 dlopen 加载进目标进程的 _inject.so
// peeka/core/_inject.c（核心逻辑）
__attribute__((visibility("default")))
int peeka_spawn_agent(int port)
{
    pthread_t thread;
    return pthread_create(&thread, NULL, &thread_body, (void*)(uintptr_t)port);
}

它创建一个 pthread，然后立即返回。Python 代码留给新线程执行，GDB 可以快速 detach，目标进程恢复正常运行。

thread_body 是这个新线程的入口函数。pthread_create 返回以后，目标进程里会多出一个线程，这个线程从 thread_body(port) 开始执行：

// 执行位置：目标进程；pthread_create 创建出的新线程
static void* thread_body(void* arg)
{
    uint16_t port = (uint16_t)(uintptr_t)arg;
    run_client(port);
    return NULL;
}

到这里，3.4 关心的事情就结束了：GDB 调用 peeka_spawn_agent(port)，目标进程创建 agent 线程，peeka_spawn_agent 立即返回。agent 线程后面会进入 run_client(port)，但它如何回连控制端、接收脚本、执行脚本，是 3.5 的内容。

独立线程降低 GIL 死锁风险

在 pyrasite 方案中，PyGILState_Ensure() 在 GDB 暂停目标进程时被调用——如果暂停的线程恰好持有 GIL，这里会死锁。

在 dlopen + pthread 方案中：

1. GDB 执行 dlopen -> spawn -> 立刻返回 -> GDB detach -> 目标进程恢复
2. 新线程随后在 run_client -> run_script 中调用 PyGILState_Ensure()，此时目标进程已经在正常运行
3. PyGILState_Ensure() 会等待 GIL 可用，避开暂停状态下的强行获取

这消除了 GIL 死锁的主要原因。

3.5 反向连接——agent 代码的传输

agent 代码的传输也很关键。peeka 采用反向连接，避免把代码内容直接写进 GDB 命令；否则字符串转义会很痛苦。

这里要区分两个概念：控制端进程是用户运行的 peeka/memray 进程；GDB/LLDB 子进程是控制端临时启动的 debugger 进程。前者负责生成和发送 agent 脚本，后者只负责把 _inject.so 加载进目标进程并调用 peeka_spawn_agent(port)。

先看完整流程：

1）peeka/memray 控制端进程：启动一个本地 TCP server，拿到监听端口。 2）GDB/LLDB 子进程：attach 目标进程，把这个端口号传给目标进程里的 peeka_spawn_agent(port)。 3）目标进程：_inject.so 中的 peeka_spawn_agent(port) 创建一个 agent 线程。 4）目标进程的 agent 线程 -> peeka/memray 控制端进程：agent 线程回连控制端的 TCP server，接收完整的 agent 脚本。 5）目标进程的 agent 线程：在目标进程内编译并执行这段脚本。

对应到源码结构，大致是下面这样。第一段是控制端逻辑，对应上面的 4）：它复用 3.1 中 _create_notify_server() 创建好的 self._notify_server，在 _serve_agent_code 中等待目标进程回连并发送 agent 脚本。

# 执行位置：peeka/memray 控制端进程；复用 3.1 创建的 self._notify_server
server_thread = threading.Thread(
    target=self._serve_agent_code,
    args=(agent_script_content, 30),
    daemon=True,
)
server_thread.start()

def _serve_agent_code(self, agent_script_content, timeout):
    server = self._notify_server
    server.settimeout(timeout)

    conn, _ = server.accept()
    try:
        conn.sendall(agent_script_content.encode("utf-8"))
    finally:
        conn.close()

第二段是目标端逻辑，对应上面的 4）和 5）：3.4 中 pthread_create 创建的新线程会从 thread_body 进入 run_client(port)，这里的 run_client 就是同一个函数。它连接控制端，读完脚本后调用 run_script，后者再获取 GIL、编译并执行 agent 代码。

// 执行位置：被 attach 的目标进程；_inject.so 创建出的 agent 线程
// 伪代码：保留主路径，省略错误处理和资源清理
static void run_client(uint16_t port)
{
    // 回连 3.1 中控制端提前监听的端口
    int sock = connect_client(port);

    // 从控制端读取完整 agent 脚本
    recvall(sock, &script, &script_len);

    run_script(script, &errmsg);
}

static int run_script(const char* script, char** errmsg)
{
    // 新线程在目标进程正常运行时等待 GIL
    PyGILState_STATE gstate = PyGILState_Ensure();
    run_script_impl(script, errmsg);
    PyGILState_Release(gstate);
}

static int run_script_impl(const char* script, char** errmsg)
{
    PyObject* builtins = PyImport_ImportModule("builtins");
    PyObject* globals = PyDict_New();
    PyDict_SetItemString(globals, "__builtins__", builtins);

    // 编译并在隔离 globals 中执行 agent 脚本
    PyObject* code = Py_CompileString(script,
                                       "_peeka_attach_hook.py",
                                       Py_file_input);
    PyObject* mod = PyEval_EvalCode(code, globals, globals);
    // ...
}

目标进程里的新线程回连 peeka/memray，主要是为了工程可靠性：agent 代码可以任意长、包含引号、换行、反斜杠、非 ASCII 字符等复杂内容，无需经过 GDB 命令行转义；GDB 只需要传一个整数端口号，注入阶段更短，出错面更小。

3.6 小结——第二代方案的完整顺序

把 3.1 到 3.5 串起来，第二代方案的完整顺序是：

1）peeka/memray 控制端先 bind(("127.0.0.1", 0)) 并 listen(1)，拿到一个本地端口，用来等待 agent 线程回连。 2）控制端启动 GDB/LLDB 子进程，并把端口号、_inject.so 路径、RTLD_NOW 等参数传给它。 3）GDB/LLDB 子进程 attach 目标进程，设置安全断点，等待目标进程自然运行到 malloc/PyMem_* 等 C 函数入口。 4）断点命中后，GDB/LLDB 在目标进程上下文里调用 dlopen("_inject.so", RTLD_NOW)。 5）GDB/LLDB 调用 peeka_spawn_agent(port)，目标进程里的 _inject.so 创建一个 pthread。 6）GDB/LLDB detach，目标进程恢复正常运行。 7）新建的 agent 线程连接控制端提前监听的端口，接收 agent 脚本。 8）agent 线程调用 PyGILState_Ensure() 等待 GIL，随后编译并执行脚本。

4. 第三代：PEP 768 与 sys.remote_exec

Python 3.14 引入了 PEP 768，从解释器层面提供了原生的进程注入支持。这是一个根本性的范式转变。

核心思路

前两代方案都从外部进入目标进程：通过 ptrace/GDB/LLDB 控制执行流，然后在一个"可能安全"的位置执行代码。PEP 768 把调度权交回解释器：外部工具告诉解释器要执行哪个脚本，解释器自己在安全检查点执行。

运作机制

外部进程                       目标 Python 解释器
    │                              │
    │  (1) 读 /proc/pid/maps       │
    │      定位 PyRuntime 地址       │
    │                              │
    │  (2) 读 _Py_DebugOffsets      │
    │      获取内部结构偏移量         │
    │                              │
    │  (3) 选择一个 PyThreadState   │
    │      通常是 main thread       │
    │                              │
    │  (4) 写入脚本路径到            │
    │      tstate->debugger_        │
    │        script_path            │
    │                              │
    │  (5) 设置 pending call 标志   │
    │      tstate->debugger_        │
    │        pending_call = 1       │
    │                              │
    │  (6) 设置 eval breaker        │
    │      eval_breaker |=          │
    │        PLEASE_STOP_BIT        │
    │                              │
    │  完成，无需等待                │
    │                              │
    │                              │  ... 正常执行字节码 ...
    │                              │
    │                              │  eval loop 检查 eval_breaker
    │                              │  ↓
    │                              │  发现 pending_call 标志
    │                              │  ↓
    │                              │  _PyRunRemoteDebugger()
    │                              │  ↓
    │                              │  读取 script_path
    │                              │  ↓
    │                              │  fopen + PyRun_AnyFile
    │                              │  ↓
    │                              │  执行脚本 ✅

这里的关键是第三步：远程执行请求必须落到某个 PyThreadState 上。sys.remote_exec(pid, script) 这个公共 API 不暴露 thread id，CPython 通常调度到目标进程的 main thread，在它下一次回到 eval loop 安全检查点时执行脚本。底层远程调试协议更通用：外部工具可以先定位解释器，再选择一个具体的 PyThreadState，常见做法是使用 threads_main，也可以遍历 threads_head 并按 native_thread_id 找到特定线程。

CPython 内部的关键代码：

// Python/ceval_gil.c
int _PyRunRemoteDebugger(PyThreadState *tstate)
{
    if (config->remote_debug == 1
        && tstate->remote_debugger_support.debugger_pending_call == 1)
    {
        tstate->remote_debugger_support.debugger_pending_call = 0;

        // 复制脚本路径（避免 race condition）
        char script_path[pathsz];
        memcpy(script_path,
               tstate->remote_debugger_support.debugger_script_path,
               pathsz);

        // 审计事件（可被安全策略拦截）
        PySys_Audit("cpython.remote_debugger_script", "s", script_path);

        // 执行脚本
        FILE* f = fopen(script_path, "r");
        PyRun_AnyFile(f, script_path);
        fclose(f);
    }
}

每个 PyThreadState 中的数据结构

远程调试字段放在 PyThreadState 里，原因在于执行请求需要绑定到某个线程的 eval loop。被选中的线程状态里会保存脚本路径和 pending 标志；这个线程运行到检查点时，才会消费这次请求。

// Include/cpython/pystate.h
#define _Py_MAX_SCRIPT_PATH_SIZE 512

typedef struct {
    int32_t debugger_pending_call;
    char debugger_script_path[_Py_MAX_SCRIPT_PATH_SIZE];
} _PyRemoteDebuggerSupport;

每个线程状态增加约 516 字节，运行时开销接近零：eval loop 中多一次分支预测极大概率命中的 if 检查。换来的好处是：每个线程都有自己的远程调试控制槽，外部工具可以把请求精确调度到某个线程状态，解释器也能在正确的线程和解释器上下文中执行脚本。

使用方式

peeka 的实现非常简洁：

# peeka/core/attach.py
def _attach_pep768(self) -> bool:
    agent_code = _read_agent_code()
    self.agent_script = self._create_agent_script(agent_code)

    # 一行搞定
    sys.remote_exec(self.pid, self.agent_script)

    # 等待 agent 就绪
    self._wait_for_agent_ready(timeout=self.READY_TIMEOUT_PEP768)
    return True

这条路径省掉了 GDB、ptrace、C 扩展和 dlopen。调用者和目标进程需要是同一用户（或拥有 CAP_SYS_PTRACE），目标进程也需要开启远程调试支持。

安全保障

PEP 768 在安全性上的设计非常审慎：

1. 仅接受文件路径：sys.remote_exec 写入的是一个文件路径，脚本内容来自目标进程可读的文件系统路径。这意味着攻击者除了跨进程写内存权限，还要放置目标进程可读的恶意脚本
2. 审计钩子：执行前触发 cpython.remote_debugger_script 审计事件，安全策略可以拦截
3. 可禁用：PYTHON_DISABLE_REMOTE_DEBUG 环境变量或 -X disable-remote-debug 启动参数
4. 编译时可移除：./configure --without-remote-debug

PEP 768 的进步

PEP 768 实现中的已知问题与 CPython 修复

PEP 768 在 Python 3.14.0a5 合入后（gh-131937），社区在实际使用中发现了一系列实现缺陷。以下按严重程度梳理关键问题及其修复方案。

其中最直观的是命名空间污染：早期实现会把注入脚本直接放在 __main__ 模块里执行，可能覆盖目标程序变量：

# 目标进程
x = 1
while x == 1:
    pass

# 注入脚本设置了 x = 42 -> 目标进程意外退出

外部工具跟进

• debugpy（VS Code）：已支持 sys.remote_exec()（2026.1），Python 3.14+ 优先使用原生 API，可通过 --disable-sys-remote-exec 回退
• helicopter-parent：社区工具，通过管理子进程绕过 ptrace_scope 限制
• peeka/memray：已集成 PEP 768 作为首选注入路径

5. 三代方案对比

memray vs peeka 的注入路径选择

两个项目虽然共享 dlopen + pthread 的核心方案，但在定位上略有不同：

memray：一次选择，快速失败。memray 在启动时通过 resolve_debugger() 按优先级（sys.remote_exec > gdb > lldb）选定一种注入方法。GDB 路径硬依赖 C 扩展，dlopen 失败直接报错。这是刻意的设计选择——memray 作为专业的内存分析器，对运行环境有明确的前置要求。

peeka：优先使用原生能力，旧版本使用 C 扩展注入。peeka 在 Python 3.14+ 上优先使用 sys.remote_exec()；更老的 Python 版本则使用 GDB/LLDB + dlopen + pthread。过去曾有过 PyRun_SimpleString 风格的 legacy 回退，但这条路径有时机安全风险，当前实现已经移除。

# peeka 的 attach 决策树
if hasattr(sys, "remote_exec"):     # Python 3.14+
    -> sys.remote_exec()              # 最优路径
elif _has_injector():                # C 扩展可用
    if Linux:
        -> GDB + dlopen + pthread
    elif macOS:
        -> LLDB + dlopen + pthread
else:
    -> 报错

这个取舍比旧版更保守：如果 C 扩展缺失、GLIBC 版本不匹配，或者 dlopen 路径运行失败，peeka 会暴露错误，拒绝回到随机暂停点执行 Python C API 的 legacy 方案。

6. 总结

Python 进程注入经历了三代演进：

1. 直接调用 C API（pyrasite）：简单粗暴，但有崩溃和死锁风险
2. dlopen + pthread（memray/peeka）：通过安全断点和独立线程显著降低风险
3. 解释器原生支持（PEP 768）：从根本上解决问题，让解释器自己在安全时机执行代码

如果你的目标环境是 Python 3.14+，sys.remote_exec 是毫无争议的最佳选择。如果需要支持更老的版本，dlopen + pthread 方案提供了合理的安全性和兼容性平衡。

进程注入落在系统编程、编译器原理和 CPython 内部机制的交汇点。理解这些底层原理，能帮助你在遇到"进程卡死"或"注入失败"时，快速定位问题所在。

本文基于 peeka 的实际开发经验撰写。peeka 是一个受 Alibaba Arthas 启发的 Python 运行时诊断工具，支持 Python 3.8-3.14+。