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

Flutter for OpenHarmony: Flutter 三方库 platform_info 为鸿蒙多端应用提供精准的运行时环境感知(平台适配大脑)

Flutter for OpenHarmony: Flutter 三方库 platform_info 为鸿蒙多端应用提供精准的运行时环境感知(平台适配大脑)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在进行 OpenHarmony 应用开发时,“环境感知”是一切进阶逻辑的基石。 * 当前是鸿蒙手机还是平板? * 应用是处于 Debug 调试态还是 Release 发布态? * 底层硬件到底有多少核处理器? 然而,由于 platform_info (v5.0.0) 尚未正式支持 OpenHarmony,直接调用会导致系统被识别为 Unknown,甚至让关键的 isMobile 判定失效。为了解决这一痛点,我们对该库进行了“手术级”的源码适配。 一、环境感知适配模型 我们将底层的系统标识符转化为 Flutter 开发者熟悉的强类型对象。 底层系统 ('ohos') 补丁适配层 (vm_host_platform) 强类型枚举

By Ne0inhk
【Linux】进程概念(六):地址空间核心机制

【Linux】进程概念(六):地址空间核心机制

引言 在计算机科学的世界里,最精妙的魔法往往隐藏在最基础的机制之中。当我们编写一个简单的printf("Hello World")时,背后正上演着一场关于内存管理的交响乐。进程地址空间、页表、缺页中断——这些看似深奥的概念,实则是现代操作系统的智慧结晶,它们共同构筑了一个让每个进程都"自以为"独占整个计算机内存的完美幻境。理解这套机制,不仅是掌握操作系统原理的关键,更是窥见计算机系统设计美学的窗口。 目录 一、程序地址空间 1.1 核心概念 一个N位的系统,其指针地址的位宽即为N比特,理论可寻址空间为 ( 2^N ) 字节。在内存布局图中,地址通常用十六进制表示。每1个十六进制数对应4个二进制位(比特)。因为一个字节(8比特位)可以用2个十六进制位数完整表示 1. 32位环境 * 地址位宽为 32比特。 * 一个完整的地址需要用 ( 32 / 4 = 8

By Ne0inhk
YOLO26来了,更好、更快、更小的 YOLO 模型,使用YOLO26训练自己的数据集和推理(附YOLO26网络结构图),租用 GPU 服务器训练教程,YOLO26创新点解析

YOLO26来了,更好、更快、更小的 YOLO 模型,使用YOLO26训练自己的数据集和推理(附YOLO26网络结构图),租用 GPU 服务器训练教程,YOLO26创新点解析

目录 * 摘要 * YOLO26更新点 * ⚡⚡C3k2 小优化 * ☑️ YOLO26 C3k2代码 * ☑️ YOLO11 C3k2代码 * ⚡⚡移除分布焦点损失(DFL) * ⚡⚡端到端、无需 NMS 推理 * ⚡⚡ProgLoss 与 STAL * ☑️ProgLoss * ☑️STAL (小目标感知标签分配) * ⚡⚡MuSGD优化器 * 从机器人到制造业:YOLO26 的用例 * 🐴一、YOLO26 源码下载与模型下载 * ⚡⚡YOLO26模型结构图 * ⚡⚡1.源码下载 * ⚡⚡2.官网的预训练模型下载 * 🐴二、数据集准备 * ⚡⚡LabelImg & Labelme * ☑️ LabelImg(仅限矩形检测框) * ☑️ Labelme * ⚡⚡ X-AnyLabeling * ⚡⚡ 旋转框 (OBB) 标注工具:roLabelImg * ⚡⚡1.目标检测数据集标注软件 * ⚡⚡2.voc数据集格式转换

By Ne0inhk
高并发系统的网络参数优化与服务超时管理(QPS 10w+)

高并发系统的网络参数优化与服务超时管理(QPS 10w+)

个人名片 🎓作者简介:java领域优质创作者 🌐个人主页:码农阿豪 📞工作室:新空间代码工作室(提供各种软件服务) 💌个人邮箱:[[email protected]] 📱个人微信:15279484656 🌐个人导航网站:www.forff.top 💡座右铭:总有人要赢。为什么不能是我呢? * 专栏导航: 码农阿豪系列专栏导航 面试专栏:收集了java相关高频面试题,面试实战总结🍻🎉🖥️ Spring5系列专栏:整理了Spring5重要知识点与实战演练,有案例可直接使用🚀🔧💻 Redis专栏:Redis从零到一学习分享,经验总结,案例实战💐📝💡 全栈系列专栏:海纳百川有容乃大,可能你想要的东西里面都有🤸🌱🚀 目录 * 高并发系统的网络参数优化与服务超时管理 * 背景与现状 * 问题分析 * 网络参数优化实践 * 1. 文件句柄限制 * 2. 调整端口范围 * 3. 连接复用 * 4. 最大连接数 * 5.

By Ne0inhk