使用Valgrind执行R CMD check时出现结果差异的问题咨询

我开发了一款R包，其中包含基于Rcpp实现的、用于计算两个3D网格交集的函数，包内附带了对应的运行示例。该函数运行时会首先校验输入网格是否存在自相交问题，若检测到自相交则抛出错误。
常规运行示例时全程无异常，但当我搭配Valgrind执行R CMD check检查R包时，该示例触发报错：代码判定第一个输入网格存在自相交（实际该网格并无自相交问题）。为何使用Valgrind时会出现这类行为差异？据我理解这部分校验逻辑和Valgrind并无关联，若前后使用的R版本完全一致，理应得到相同的运行结果，特此咨询出现该差异的具体原因。

这类行为差异几乎都来自内存错误或运行环境的计算逻辑差异，和Valgrind本身不会主动修改代码逻辑的认知不冲突，具体可分为三类：

• 未初始化内存读取：常规运行时，系统新分配给程序的内存通常会残留历史运行数据，或被默认填充为0。如果C++代码中声明的局部变量、数组、临时缓冲区没有显式初始化，这些位置的取值刚好不会触发自相交判定的分支，程序运行就表现正常。Valgrind的Memcheck模块会将所有未初始化的内存标记为特殊的未定义状态，只要代码读取这类内存参与几何计算（比如三角形相交判断、坐标差值计算、阈值比较），后续的条件判断结果就会和常规运行完全不同，直接触发假阳性的自相交报错。
• 浮点计算行为差异：Valgrind运行程序时不会模拟部分CPU的高级浮点扩展指令（如AVX、FMA指令集），如果你编译R包时开启了激进的浮点编译优化，常规运行时这些优化指令产生的浮点误差刚好让计算结果落在“无自相交”的判定区间；Valgrind环境下计算会回退到标准IEEE 754双精度计算逻辑，误差波动可能让结果刚好跨过判定阈值，触发错误判定。
• 内存越界篡改输入数据：如果Rcpp代码存在数组越界写、悬空指针访问、访问已释放内存的问题，常规运行时的进程内存布局下，越界写入的位置不会碰到存储网格顶点、面片索引的内存块，自然不会影响校验结果；Valgrind会重新排布程序的内存布局、在内存块之间添加边界保护页，越界写入的位置可能刚好落在网格数据的存储区域，直接篡改了坐标或索引值，原本正常的网格就会被判定为存在自相交。

• 不要只关注R最终抛出的自相交错误，逐行梳理Valgrind输出的所有诊断信息，优先定位Invalid read of size、Invalid write of size、Conditional jump or move depends on uninitialised value三类报错对应的代码行，这类内存错误的影响点往往和触发点相隔很远，是导致逻辑异常的核心原因。
• 在自相交校验函数的入口处添加调试打印逻辑，输出所有输入的顶点坐标、面片索引值，对比Valgrind环境和常规运行环境的输入数据是否完全一致，如果数据存在差异，说明在校验逻辑执行前已经发生了内存篡改。
• 编译R包时添加-O0 -g编译参数、关闭所有浮点优化选项后重新在Valgrind下运行，排除编译优化带来的浮点计算差异干扰。

内容的提问来源于stack exchange，提问作者Stéphane Laurent