【问题反馈】JNI 开发:为什么 C++ 在 Debug 正常,Release 却返回 NaN?

【问题反馈】JNI 开发:为什么 C++ 在 Debug 正常,Release 却返回 NaN?
摘要:
在 Android NDK / JNI 开发中,经常会遇到这样一种“诡异”问题:Debug 模式下运行完全正常,而 Release 模式却出现 NaN、Infinity 甚至随机结果。
本文通过一次真实的 JNI 坐标转换案例,深入分析了该问题的根本原因——C++ 返回局部栈内存指针所导致的未定义行为(Undefined Behavior)。

请添加图片描述

【问题反馈】JNI 开发:为什么 C++ 在 Debug 正常,Release 却返回 NaN?

本文为以下问题的解决记录。由于问题较为典型,故梳理备忘。
https://github.com/eqgis/Sceneform-EQR/discussions/16

一、问题现象描述

1. 现象

  • Debug 构建
    • JNI 返回的坐标数值正常
  • Release 构建
    • 返回坐标中出现 NaN / Infinity

且仅在Release出现

2. 出问题的方法

JNIEXPORT void JNICALL Java_com_eqgis_eqr_core_CoordinateUtilsNative_jni_1ToScenePosition( JNIEnv *env, jclass clazz, jdouble ref_x, jdouble ref_y, jdouble target_location_x, jdouble target_location_y, jdouble azimuth_rad, jdoubleArray outJNIArray){double*offset =ComputeTranslation(ref_x, ref_y, target_location_x, target_location_y);double deX =*offset;double deY =*(offset +1);double x = deX *cos(azimuth_rad)- deY *sin(azimuth_rad);double y = deX *sin(azimuth_rad)+ deY *cos(azimuth_rad);double outArray[]={x, y}; env->SetDoubleArrayRegion(outJNIArray,0,2, outArray);}

二、问题根因定位:一个“看起来没问题”的函数

问题最终锁定在这个函数:

double*ComputeTranslation(double x1,double y1,double x2,double y2){double res[2]={0,0};... res[0]= flagX * x; res[1]= flagY * y;return res;}

乍一看逻辑完全正确,但这里隐藏了一个致命错误


三、致命问题:返回了栈内存指针(未定义行为)

1. res 是什么?

double res[2];
  • res函数内部的局部变量
  • 存储在 当前函数的栈帧(stack frame)中

2. 函数返回后发生了什么?

ComputeTranslation 返回时:

  • 函数栈帧被销毁
  • res 对应的内存 立刻失效
  • 返回的指针指向:
    • 已被释放的栈空间
    • 或即将被复用的内存区域

3. C++ 标准如何定义这种行为?

这是典型的 Undefined Behavior(未定义行为)

含义是:

  • 编译器不保证任何结果
  • 程序:
    • 可能“看起来能跑”
    • 也可能随机崩溃
    • 也可能只在 Release 模式出问题

四、为什么 Debug 正常,而 Release 出 NaN?

这是很多开发者最困惑的地方。

1. Debug 模式的特点

  • 编译器优化极少
  • 栈内存分配保守
  • 局部变量:
    • 生命周期“看起来”更长
    • 内存内容不容易被覆盖

返回的指针虽然非法,但数据暂时还在


2. Release 模式的特点

  • 启用 -O2 / -O3 等激进优化
  • 栈空间:
    • 快速复用
    • 指令重排
    • 寄存器替代变量

编译器甚至可能认为:

“你返回这个指针是非法的,那我随便优化”

结果就是:

  • *offset 变成随机值
  • 或直接成为 NaN / Inf

五、为什么 NaN 特别容易出现?

在 Release 下,offset 可能是:

  • 未初始化内存
  • 被 SIMD / 浮点寄存器覆盖
  • 任意 bit pattern

浮点数中

  • 特定 bit pattern ⇒ NaN
  • 一旦参与计算:
    • NaN + x = NaN
    • sin(NaN) = NaN

导致后续都是NaN


六、这不是 JNI 的问题

值得特别强调的是:

  • JNI 只是一个函数调用边界
  • 问题在 C++ 层就已经发生
  • Java 侧只是“忠实地接收了 NaN”

如果这是纯 C++ 工程:

  • 现象 完全一致

七、正确修复方式:返回值语义而不是指针

修复方案:使用结构体返回

structVec2{double x;double y;}; Vec2 ComputeTranslation(double x1,double y1,double x2,double y2){ Vec2 res{0.0,0.0};... res.x = flagX * x; res.y = flagY * y;return res;}

调用:

Vec2 offset =ComputeTranslation(...);double deX = offset.x;double deY = offset.y;

八、为什么“以前这么写也没事”?

原因通常是:

  1. 旧编译器优化弱
  2. Debug 构建长期被使用
  3. 数据规模较小
  4. 没踩到“恰好会覆盖栈”的场景

但:

未定义行为从来不是“偶尔才错”,而是“早晚会炸”。

九、如何系统性避免这类问题?

1. 永远不要返回局部变量地址

return&localVar;return localArray;

2. 优先使用值语义

struct/ std::array / std::pair 

3. Debug ≠ 正确

Debug 只能说明:

“在当前编译条件下恰好没炸”

十、总结

问题结论
Debug 正常不代表代码正确
Release 出 NaN典型 UB 表现
根因返回栈内存指针
JNI 是否有问题没有
正确解法返回结构体 / 值语义

这次问题再次验证了一点:

C++ 中,最危险的 Bug 往往不是“复杂算法”,
而是“看起来理所当然的代码”。

如果在 Debug / Release 行为不一致时遇到诡异问题,
第一时间检查:是否触发了未定义行为。


Read more

C++ 入门篇 (七)

文章目录 * C++ 入门篇 (七) * 1.对象拷贝时编译器的优化 * 2.C++里的内存管理 * 1.复习 * 2.C++里面的动态内存管理 * 3.new 和 delete 的底层 * operator new 和 operator delete * 定位new (placement) C++ 入门篇 (七) 1.对象拷贝时编译器的优化 编译器在进行编译的时候,会对一下需要拷贝的情况进行优化,像我们之前提到了构造+拷贝构造优化成直接构造。当然,这个优化是根据编译器的情况来决定的,一些老的编译器可能就没有,而一些新的编译器优化力度更大一些,或者说更激进一些,可能会存在跨行优化。在release版本下,优化力度会更大。 优化主要是在拷贝的时候发生,比如传值传参,或者传值返回。之前我们讲到的是隐式类型转换的时候,“1” 先去构造一个临时对象,然后再拷贝构造到初始化的对象里面,

By Ne0inhk
C++ ODB ORM 完全指南:从入门到实战应用

C++ ODB ORM 完全指南:从入门到实战应用

文章目录 * ODB基本概念 * ODB框架安装 * 常见操作 * ODB类与接口 * 测试示例 ODB基本概念 ODB 是一个针对 C++ 的对象关系映射(ORM)库,它允许开发者以面向对象的方式操作数据库,将C++ 对象与数据库表进行映射,从而避免直接编写 SQL 语句,简化数据库操作。 特点: * 对象 - 关系映射:将 C++ 类映射到数据库表,类的成员变量映射到表的字段,对象的创建、修改、删除等操作会自动转换为对应的数据库操作(如 INSERT、UPDATE、DELETE)。 * 代码生成机制:ODB 不依赖运行时反射(C++ 本身不支持),而是通过编译期代码生成实现映射:开发者使用特殊的注解(如 #pragma db object)标记需要持久化的类,然后通过 ODB 编译器生成与数据库交互的代码(

By Ne0inhk
【C++】现代C++的新特性constexpr,及其在C++14、C++17、C++20中的进化

【C++】现代C++的新特性constexpr,及其在C++14、C++17、C++20中的进化

各位读者大佬好,我是落羽!一个坚持不断学习进步的学生。 如果您觉得我的文章还不错,欢迎多多互三分享交流,一起学习进步! 也欢迎关注我的blog主页:落羽的落羽 文章目录 * 一、从C++11引入 * 1. 常量表达式和constexpr关键字的概念 * 2. constexpr修饰函数 * 二、constexpr在C++14中的进化 * 三、constexpr在C++17中的进化 * 四、constexpr在C++20中的进化 一、从C++11引入 1. 常量表达式和constexpr关键字的概念 现代C++,从C++11开始,引入了常量表达式和constexpr关键字的概念,并且在之后的C++标准中不断更新 常量表达式是指,值不会改变并且在编译过程中就能得到计算结果的表达式。用字面量、常量表达式初始化的const对象都是常量表达式。但是用变量初始化的const对象不是常量表达式。 constint a =1;//a是常量表达式constint b = a +1;//b是常量表达式int c

By Ne0inhk
C++ 二叉搜索树全解析!增删查改 + key/value 场景 + 完整代码,一篇通关

C++ 二叉搜索树全解析!增删查改 + key/value 场景 + 完整代码,一篇通关

✨ 孤廖:个人主页 🎯 个人专栏:《C++:从代码到机器》 🎯 个人专栏:《Linux系统探幽:从入门到内核》 🎯 个人专栏:《算法磨剑:用C++思考的艺术》 折而不挠,中不为下 文章目录 * 正文: * 1. ⼆叉搜索树的概念 * 2. ⼆叉搜索树的性能分析 * 3. ⼆叉搜索树的插⼊ * 4. ⼆叉搜索树的查找 * 5. ⼆叉搜索树的删除 * 6. ⼆叉搜索树key和key/value使⽤场景 * 6.1 key搜索场景: * 6.2 key/val搜索场景 * 7. ⼆叉搜索树的实现代码 * 7.1 key模型代码实现 * 7.2 key/val代码实现 * 结语 正文: 1. ⼆叉搜索树的概念

By Ne0inhk