【问题反馈】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 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系

Flutter 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系 前言 在 OpenHarmony 鸿蒙应用追求“万物互联、全场景覆盖”的伟大进程中,屏幕尺寸的多样性(从 6 英寸手机到 12 英寸平板,再到 2D/3D 模式切换的折叠屏)是每一位 UI 开发者必须正面迎接的挑战。如何在不为每种设备重写 UI 的前提下,实现导航栏自动从“底部”平滑流转到“侧边”?如何在宽屏模式下自动开启“双栏(Master-Detail)”布局?flutter_adaptive_scaffold 作为一个由 Flutter

By Ne0inhk
在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程

在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程

在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程 什么是 OpenClaw?—— 你的本地 AI 智能体执行框架 OpenClaw 不仅仅是一个聊天机器人,而是一个功能强大的 AI 智能体执行框架。你可以把它想象成一个能自主思考、调用工具、并替你完成复杂任务的数字员工。 🧠 核心概念 * 智能体:OpenClaw 的核心大脑。它能理解你的自然语言指令,拆解任务,并决定调用哪些工具来执行。 * 网关:所有外部访问的入口。它负责处理 WebSocket 连接、管理设备配对、路由消息,是你与智能体交互的桥梁。 * 技能:智能体可调用的具体工具,比如访问文件、操作浏览器、发送消息、查询数据库等。你可以根据需要扩展技能库。 * 记忆:OpenClaw 可以存储对话历史和重要信息,实现长期记忆和上下文理解,让交互更连贯。 * 通道:连接外部聊天平台的渠道,如

By Ne0inhk
HarmonyOS6半年磨一剑 - RcIcon组件实战案例集与应用开发指南

HarmonyOS6半年磨一剑 - RcIcon组件实战案例集与应用开发指南

文章目录 * 前言 * 项目简介 * 核心特性 * 开源计划 * rchoui官网 * 文档概述 * 第一章: 基础用法实战 * 1.1 三种符号引用方式 * 1.2 应用场景 - 工具栏快速导航 * 第二章: 尺寸系统实战 * 2.1 响应式尺寸配置 * 2.2 应用场景 - 统一设计系统尺寸规范 * 第三章: 颜色系统实战 * 3.1 多彩色系配置 * 3.2 应用场景 - 状态指示系统 * 第四章: 双风格系统实战 * 4.1 线型与实底风格对比 * 4.2 应用场景 - 底部导航栏 * 第五章: 圆角系统实战 * 5.

By Ne0inhk
Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构

Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构 前言 在鸿蒙(OpenHarmony)生态迈向万物互联、涉及海量离线资源标识、蓝牙广播载荷(BLE Payload)及二维码数据极限压缩的背景下,如何生成既能保留 UUID 强随机性、又能极大缩减字符长度的唯一标识符,已成为优化存储与通讯效率的“空间必修课”。在鸿蒙设备这类强调分布式软总线传输与每一字节功耗敏感的环境下,如果应用依然直接传输长度达 36 字符的标准 UUID,由于由于有效载荷溢出,极易由于由于传输协议限制导致数据截断或多次分包带来的延迟。 我们需要一种能够实现高进制转换、支持双向编解码且具备低碰撞概率的短 ID 生成方案。 short_uuids 为 Flutter 开发者引入了将标准 UUID 转化为短格式字符串的高性能算法。它利用

By Ne0inhk