【问题反馈】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

OpenCode 免费模型深度评测:四大开源模型场景化对比与选型指南

OpenCode 免费模型深度评测:四大开源模型场景化对比与选型指南

在开源大语言模型(LLM)生态中,OpenCode 凭借其多样化的免费模型矩阵(如 Trinity Large Preview、Big Pickle、MiniMax M2.5 Free、GPT-5 Nano)吸引了开发者与企业的广泛关注。本文将从技术架构、性能表现、适用场景等维度,深度解析这四大模型的差异化优势,并提供选型建议。 1. Trinity Large Preview:超大规模稀疏模型的“创意引擎” 开发者:Arcee AI 核心架构:400B 参数稀疏混合专家(MoE)架构,每 token 仅激活 13B 参数 上下文窗口:512K tokens(约 75 万字) 适用场景:创意写作、

By Ne0inhk
【工创赛2025-智能物流搬运塔吊方案视觉开源(2分15秒)】西安理工大学工程训练中心

【工创赛2025-智能物流搬运塔吊方案视觉开源(2分15秒)】西安理工大学工程训练中心

一、前言         本文也是我的第一篇ZEEKLOG博客,主要内容是记录一下2025年工训赛的参赛过程,讲解一下与louisaerdusai学长一起开发的智能物流视觉方案。主要内容为:实现函数、串口与下位机的通讯和整个实现流程,希望我们的经验能够帮助大家。         本文为视觉算法开源,其他部分开源请移步:【工创赛2025-塔吊结构方案开源(2分15秒)】西安理工大学工程训练中心-ZEEKLOG博客 二、本届视觉设计由来         我在今年校赛阶段参加的是智能救援赛道,由于我们机械设计的过于复杂和一些其他原因,机械结构的反复修改,最终没有尽快实现视觉与机械结构联调,导致我们在校赛就遗憾出局。在校赛遗憾结束后,我有幸加入了学长的队伍,在重新了解了物流搬运的视觉流程后,发现使用Jetson Nano运行OpenCV算法算是更加灵活的选择。但是在省赛是我也发现很多队伍采用的OpenMV方案也可以流畅运行,就我使用这些微型视觉模块的经验来说,我推荐使用MaixCAM pro来实现简单的算法,但是不得不说OpenCV的算法实现是更加通用且灵活的,同时使用OpenCV算

By Ne0inhk
git笔记之默认使用vim以及修改倒数第二次的commit提交信息到远程

git笔记之默认使用vim以及修改倒数第二次的commit提交信息到远程

git笔记之默认使用vim以及修改倒数第二次的commit提交信息到远程 code review! 文章目录 * git笔记之默认使用vim以及修改倒数第二次的commit提交信息到远程 * 一.默认使用vim方法之一:使用 `git config` 命令 * 二.修改倒数第二次的commit提交信息到远程 * 操作步骤 * 第一步:启动交互式变基 (Interactive Rebase) * 第二步:选择要修改的提交 * 第三步:修改提交信息 * 第四步:强制推送到远程 * 总结流程图 * 常见问题:如果在 Rebase 过程中遇到冲突怎么办? 一.默认使用vim方法之一:使用 git config 命令 这是最直接且专门针对 Git 的设置方法。打开的终端(Terminal)或 Git Bash,运行以下命令: git config --global core.editor "

By Ne0inhk

OpenClaw 最新功能大揭秘!2026年最火开源AI Agent迎来史诗级升级,手机变身AI终端不是梦

OpenClaw 最新功能大揭秘!2026年最火开源AI Agent迎来史诗级升级,手机变身AI终端不是梦 大家好,我是Maynor。最近开源社区彻底炸锅了——OpenClaw(前身Clawdbot/Moltbot)又一次刷屏!这个能真正“干活”的本地AI助手,在3月2日刚刚发布v2026.3.1版本,紧接着2月底的v2026.2.26也是里程碑式更新。 从外部密钥管理、线程绑定Agent,到Android深度集成、WebSocket优先传输……OpenClaw正在把“AI常驻员工”从概念变成现实。 今天这篇图文并茂的干货,带你一口气看懂最新功能、安装上手和实战价值!

By Ne0inhk