rr录制需程序持续运行，否则静默降级为非确定性ptrace；重放依赖原路径源码和-g编译；反向执行受限于函数边界和内核checkpoint支持。
rr 录制时程序没反应或直接退出
rr 不是普通调试器，它要求被录制的程序能正常启动并持续运行——哪怕只是 sleep。如果 rr record ./a.out 看似执行了但立刻返回，大概率是程序本身启动即退出（比如没加 getchar() 或 sleep(10)），或者被 rr 拦截失败（如用了 setuid、seccomp 或某些容器环境）。
- 确保程序至少有一个可阻塞的点：加
std::this_thread::sleep_for(std::chrono::seconds(10))或getchar()在末尾 - 避免在 Docker 默认配置下用 rr；若必须，启动容器时加
--cap-add=SYS_PTRACE --security-opt seccomp=unconfined - rr 无法录制已用
ptrace的进程（比如已被gdb附加过），也不能录制内核模块或直接操作硬件的程序
重放时 gdb 找不到源码或断点不命中
rr 重放本质是“确定性回放”，但它不保存源码路径，只记录指令执行流。所以 rr replay 启动的 gdb 能单步、看寄存器、查堆栈，但若源码不在原路径，list 会报错，break main 可能命中不到行号。
- 重放前先确认当前目录和录制时一致；否则用
directory /path/to/src告诉 gdb 源码位置 - 编译时务必带
-g，且避免-O2以上优化——rr 对内联、尾调用等优化支持有限，断点可能跳到意外位置 - 用
rr replay -x .gdbinit加载自定义 gdb 初始化脚本，提前设置directory和常用别名
rr record 报错 “Failed to set up reverse-execution support”
这是 rr 最典型的兼容性报错，根本原因是内核未启用 CONFIG_CHECKPOINT_RESTORE 或用户态缺少必要权限。它和普通 ptrace 权限不同，需要显式允许 checkpoint/restore 功能。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 检查内核配置：
zcat /proc/config.gz | grep CHECKPOINT_RESTORE（若无此文件，查/boot/config-$(uname -r)） - 临时开启（需 root）：
echo 1 | sudo tee /proc/sys/kernel/unprivileged_userns_clone（部分发行版需先sudo modprobe overlay） - Arch/Manjaro 用户注意：默认内核可能禁用该选项，换用
linux-zen或手动编译内核
想跳转到某次内存写入发生的位置，但 reverse-step 不生效
reverse-step 和 reverse-next 依赖 rr 的反向执行能力，但它们只对“当前函数内”的控制流有效；一旦跳出函数（比如从 malloc 返回），rr 无法自动倒推进系统调用内部，此时会停在函数入口而非调用点。
立即学习“C++免费学习笔记（深入）”；
- 优先用
rr watch -l &my_var监听变量地址变化，触发后直接reverse-continue回溯到首次写入处 - 避免在 heavily optimized 代码中依赖
reverse-step；改用watchpoint+record instruction-trace（性能开销大，仅调试关键段） - rr 不支持跨 fork 的反向执行；若 bug 出现在子进程中，得用
rr ps找到对应 trace 目录，再rr replay -p PID
rr 的确定性重放很强大，但它的“确定性”是有前提的：内核支持、编译方式、运行环境、甚至系统时间戳读取方式都可能破坏它。最常被忽略的是——你以为录下来了，其实 rr 已静默降级为普通 ptrace 录制，这时重放就不再是确定性的。每次 rr record 后，顺手跑一遍 rr status 看一眼 recording method 是不是 ptrace 还是 checkpoint，能省掉一大半诡异问题。
