使用PTRACE_SEIZE跟踪子进程时，SIGCONT触发SIGTRAP的PTRACE_EVENT_STOP原因咨询

我之前也踩过这个坑，查了内核源码和实际测试才搞清楚——这是PTRACE_SEIZE模式下内核的隐含行为，虽然ptrace(2)手册没明确提及，但逻辑上是为了让跟踪进程能干预被跟踪进程从停止状态恢复的关键过程。下面详细拆解：

• PTRACE_SEIZE的异步特性是核心诱因
  不同于PTRACE_ATTACH会立即暂停目标进程，PTRACE_SEIZE是异步跟踪模式，它不会主动打断目标执行，只在进程进入关键状态时通知跟踪端。当被跟踪进程收到SIGCONT时，它会从之前的停止状态（比如被SIGSTOP暂停）恢复执行，内核认为这个状态转换需要让跟踪进程知晓并可能干预，因此会生成一个PTRACE_EVENT_STOP，用SIGTRAP作为信号传递给跟踪进程。

• 文档缺失的原因
  ptrace(2)手册的更新往往滞后于内核实现细节，这个行为属于内核为完善异步跟踪逻辑添加的隐含处理，并没有在手册中明确列出。你可以查看Linux内核源码（比如kernel/ptrace.c中的ptrace_signal_deliver函数）看到相关逻辑：当被跟踪进程处理SIGCONT且处于PTRACE_SEIZE跟踪状态时，内核会触发PTRACE_EVENT_STOP，确保跟踪进程有机会在进程恢复前做处理。

• 如何识别这个特定停止事件
  你可以通过两种方式区分它和其他PTRACE_EVENT_STOP：

  • 调用ptrace(PTRACE_GETEVENTMSG, ...)获取事件的详细信息，确认触发源
  • 结合上下文判断：如果之前被跟踪进程处于停止状态，且当前收到的SIGTRAP伴随PTRACE_EVENT_STOP，大概率是SIGCONT触发的

• 处理建议
  当你的跟踪进程收到这个SIGTRAP类型的PTRACE_EVENT_STOP时，可以根据需求选择：

  • 直接调用ptrace(PTRACE_CONT, ...)让被跟踪进程继续执行
  • 先执行读取内存、修改寄存器等跟踪操作，再恢复进程

内容的提问来源于stack exchange，提问作者Andrew Gunnerson