同一Docker镜像下Valgrind Memchk在不同主机结果不一致排查

Docker配置差异排查 #

• 检查容器文件描述符（FD）限制：Valgrind的断言失败与FD数量直接相关。分别在两台机器上执行docker run --rm debian:testing ulimit -n对比默认FD上限。若机器B的数值偏低，启动容器时手动指定更高限制：docker run --ulimit nofile=1024:4096 ...
• 验证seccomp规则：Fedora的Docker默认seccomp规则可能更严格，阻碍Valgrind的FD操作。在机器B上启动容器时添加--security-opt seccomp=unconfined测试是否解决问题
• 检查容器用户权限：确认两台机器运行容器的UID/GID一致，且对测试目录/builds/user/boost-multi/build/Testing/Temporary/有读写权限，避免因权限问题导致Valgrind无法生成日志文件

内核兼容性问题 #

• 升级Valgrind版本：你使用的Valgrind 3.19.0发布于2022年，对Fedora 37的6.1.x新内核支持不足。在debian:testing镜像中升级Valgrind到最新稳定版（如3.21.0），重新构建镜像后测试
• 对比内核配置：导出两台主机的内核配置（zcat /proc/config.gz），重点排查与内存调试、文件描述符相关的选项，看Fedora内核是否开启了Valgrind不兼容的特性

Valgrind参数优化 #

• 移除--trace-children=yes：该参数会追踪所有子进程，可能导致FD占用激增触发断言。若测试无需追踪子进程，关闭此选项尝试
• 调整抑制规则生成参数：--gen-suppressions=all会生成大量抑制规则，增加FD消耗。改为--gen-suppressions=yes或暂时关闭该参数
• 手动设置最大FD限制：添加--max-fd=256（或更高值，如1024）参数，覆盖Valgrind默认的FD上限，避免触发断言

镜像内环境验证 #

• 手动复现并追踪：在机器B上启动镜像进入交互模式，手动运行单个Valgrind测试，同时用strace valgrind [你的测试命令]追踪系统调用，定位FD操作的异常点
• 检查镜像内ulimit：在镜像内执行ulimit -n确认默认FD限制，必要时在镜像启动脚本中添加ulimit -n 1024提升上限

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