Valgrind启动时shmat失败报Invalid argument，本质是其地址空间约束比内核严格，导致默认NULL地址映射冲突；解决方法是强制指定shmat的shmaddr（如0x10000000），避开Valgrind保留区，并确认程序能完成初始化后再使用--vgdb-error等调试参数。
Valgrind 启动就报错 shmat 失败？先绕过共享内存初始化
Valgrind 无法启动、卡在 shmat 调用并报 Invalid argument，本质是它对共享内存段地址映射的约束比内核更严格。默认情况下，程序调用 shmat 时若未指定 shmaddr（即传 NULL），内核会选一个可用地址；但 Valgrind 的地址空间布局和影子内存管理机制会让这个“随机地址”大概率撞上它的保留区，直接失败。
解决方法不是改 Valgrind，而是改你的程序——强制指定共享内存附加地址：
- 把
shmat(shmid, NULL, 0)改成shmat(shmid, (void*)0x10000000, 0)这类明确、远离低地址和高位保留区的值（如0x10000000、0x20000000） - 确保该地址未被其他 mmap 区域占用（可用
/proc/[pid]/maps验证） - 如果程序由第三方库控制
shmat调用（如某些 IPC 框架），需查文档看是否支持传入自定义基址，或设环境变量（如SHM_BASE_ADDR=0x10000000）触发其内部适配
--vgdb-error=0 不生效？确认 Valgrind 是否真卡在启动点
--vgdb-error=0 本意是让 Valgrind 一启动就暂停、开 GDB server 等你 attach，但它只对“能跑起来”的程序有效。如果你的程序在 main 之前就因共享内存失败而退出，Valgrind 根本没机会执行到挂起逻辑。
验证方式很简单：加 --log-file=valgrind-start.log 后运行，打开日志看有没有出现 TO CONTROL THIS PROCESS USING vgdb 行。没有？说明程序连 Valgrind 的初始化阶段都没过完。
此时必须先解决前置依赖（比如上面的 shmat 地址问题），否则 --vgdb 系列参数全是空谈。
想跳过构造函数/全局对象初始化？用 --run-libc-freeres=no + --track-fds=no
有些程序在全局对象构造阶段就访问非法内存，但 Valgrind 默认会先运行 libc 自己的清理器（__libc_freeres），这可能掩盖或干扰你真正想观察的初始化路径。
加上这两个参数可大幅简化启动初期行为：
-
--run-libc-freeres=no：跳过 libc 内部的释放逻辑，避免它提前触碰可疑内存 -
--track-fds=no：不监控文件描述符操作，减少初始化时的系统调用干扰 - 再配合
--vgdb-error=1（第一个错误就停），比=0更可靠——只要程序能走到第一个实际错误点，就能断住
VSCode attach 不上？别连 a.out，连 Valgrind 自己的 GDB server
常见误区：在 VSCode 里配置 launch.json 为 "mode": "attach" 后，去 attach 你编译出的 a.out 进程。这是错的。
Valgrind 启动后，自己会 fork 出一个 GDB server 子进程，监听类似 127.0.0.1:12345 的端口（日志里有 ==12345== TO CONTROL... 提示）。VSCode 必须连这个端口，而不是原进程 PID。
关键点：
- 确保 launch.json 中
"type"是"cppdbg"，且"request"是"attach" -
"processId"字段不要填——它对远程 GDB attach 无效；应填"miDebuggerServerAddress": "localhost:12345" - 端口号必须和 Valgrind 日志里显示的一致，每次运行都可能不同
最易被忽略的是：Valgrind 的 GDB server 只响应一次 attach。如果 VSCode 连失败（比如端口填错），它不会重试，整个调试会话就废了——必须重启 Valgrind。
