跨节点ptrace迁移进程栈与寄存器触发Stack smashing detected排查

报错根因 #

你触发的Stack smashing detected是栈溢出保护（SSP）校验失败的标准报错，核心原因是当前方案遗漏了必要的状态同步，该技术路线本身完全可行，属于用户态检查点/恢复（CRIU）的精简实现场景，不存在原理性障碍。
具体到你的测试场景，关闭ASLR仅能保证内存段基址不随机，但每个进程启动时生成的栈金丝雀（canary，栈保护校验值）是独立随机生成的，存储在线程本地存储（TLS）段内，不属于ASLR控制范围。你仅同步了栈、堆、通用寄存器，没有同步TLS段数据：2号节点TLS中存储的自身canary基准值，和你从1号节点拷贝过来的main函数栈帧中存储的1号节点canary值不匹配，等add_one执行完返回main函数、执行栈校验逻辑时，就会直接触发栈保护报错。
另外你选择add_one函数入口作为断点也存在潜在问题：如果断点停在函数prologue（栈帧建立逻辑）执行前，两侧进程的栈帧状态可能存在细微差异，也容易引发栈结构损坏。

当前方案的明确遗漏点 #

• 未同步TLS（线程本地存储）段全量数据：除了栈canary，TLS中还存储了线程ID、errno、glibc线程上下文等核心状态，不同步会引发各类隐性错误。
• 未同步全量寄存器：你可能只同步了通用整数寄存器，遗漏了fs/gs段寄存器（x86_64架构下gs寄存器专门用于寻址TLS段，不同步会直接导致TLS访问错误）、SSE/AVX浮点寄存器、rflags标志寄存器等状态。
• 内存段同步不全：你仅同步了栈和堆，没有同步所有可写的匿名映射、私有映射段，包括glibc全局状态段、vDSO可写数据等。
• 未做内存映射一致性校验：没有提前比对两侧进程的/proc/<pid>/maps映射表，无法保证所有段的地址、权限、偏移完全一致，哪怕存在一个段的映射偏差，覆写后都会出现内存错误。

你提到跳过内核栈拷贝的操作是合理的：在两侧内核版本一致、停在完全相同的用户态指令地址、用户态寄存器全量同步的前提下，内核栈不需要单独拷贝，不会引发问题。

测试场景快速验证步骤 #

针对你当前的极简测试程序，按以下步骤操作可以快速跑通流程：

1. 编译测试程序时关闭栈保护和PIE，排除无关变量干扰，编译命令为：

gcc -fno-stack-protector -no-pie -o test_migrate test.c

2. 调整断点位置：不要打在add_one函数入口，而是打在add_one内部*p += 2对应的指令地址上，也就是函数prologue（push rbp、栈帧建立、canary压栈）执行完成的位置，此时两侧进程的栈帧结构完全对齐。
3. 1号节点停在断点后，抓取以下数据：
   • 全量寄存器状态：包括所有通用寄存器、gs/fs段寄存器、浮点/向量寄存器、rflags寄存器
   • 所有可写内存段数据：从/proc/<pid>/maps中提取所有权限为可写（w）的段，包括栈、堆、TLS、glibc全局数据段，按地址范围全量读取
4. 2号节点停在完全相同的断点地址后，先全量覆写所有寄存器值，再按相同地址逐段覆写所有可写内存段数据，覆写使用ptrace的POKEDATA操作即可，不要修改目标进程的内存权限。
5. 恢复2号节点进程执行到add_one返回main的位置，抓取返回结果和对应寄存器、内存状态，回传到1号节点覆写后恢复执行即可。

通用场景落地必做步骤 #

如果要迁移真实业务应用，还需要补全以下状态的同步：

• 比对两侧进程的/proc/<pid>/maps全表，保证所有代码段、共享库、匿名映射、文件映射的地址、权限、文件偏移完全一致，不一致时需要先在2号节点做内存映射调整，再做数据覆写。
• 同步内核维护的进程上下文：包括信号掩码、替代信号栈（sigaltstack）、打开的文件描述符表、当前工作目录、umask、进程权限等状态。
• 多线程场景下需要给每个线程单独停断点，同步每个线程的栈、寄存器、TLS状态，不要遗漏线程私有数据。

内容的提问来源于stack exchange，提问作者Abilesh Sundarasamy