暂无最小复现工程。业务是常规 vue3 页面加 uview-plus，没有自写的 NAPI / JSVM 调用。崩溃只在 AGC 云测试长时间自动遍历页面时出现，本地还没有做过长时间压测去复现。
pkugongyi
- 发布：2026-10-27 16:08
- 更新：2026-10-27 18:30
- 阅读：116
【报Bug】鸿蒙 vue3：libjsruntime.so 在 ProcessAll 中 napi_delete_reference 崩溃（5.31/5.33 均复现）
分类：鸿蒙Next
产品分类： uniapp/App
PC开发环境操作系统： Windows
PC开发环境操作系统版本号： Windows 11（10.0.26300）
手机系统： HarmonyOS NEXT
手机系统版本号： HarmonyOS 6.0.0
手机厂商： 华为
手机机型： HUAWEI Pura 90 Pro Max；HUAWEI MateBook Pro（HAD-W24）
页面类型： vue
vue版本： vue3
打包方式： 离线
项目创建方式： CLI
CLI版本号： 3.0.0-5030320261023001（HBuilderX 5.33.2026102401 正式版同代）
示例代码：
操作步骤：
- 打 release 包（.app），上传 AGC，执行「上架自检」（或云测试的稳定性测试）。
- 云测机自动遍历页面 0.5～1 小时，反复 navigateTo / navigateBack。
- 偶发 Cpp Crash：应用 A 这次自检 5 台设备、110 个用例里出现 1 次；应用 B 上一次自检也出现 1 次。
- 打 release 包（.app），上传 AGC，执行「上架自检」（或云测试的稳定性测试）。
- 云测机自动遍历页面 0.5～1 小时，反复 navigateTo / navigateBack。
- 偶发 Cpp Crash：应用 A 这次自检 5 台设备、110 个用例里出现 1 次；应用 B 上一次自检也出现 1 次。
预期结果：
长时间运行、频繁切页时不崩溃，上架自检稳定性通过。
长时间运行、频繁切页时不崩溃，上架自检稳定性通过。
实际结果：
进程 SIGSEGV(SEGV_MAPERR) 退出，生成 cppcrash，AGC 上架自检判稳定性「不通过」。
进程 SIGSEGV(SEGV_MAPERR) 退出，生成 cppcrash，AGC 上架自检判稳定性「不通过」。
bug描述：
问题概述
鸿蒙 uni-app（vue3，非 uni-app x）release 包在华为 AGC「上架自检」的稳定性测试里偶发 Cpp Crash（SIGSEGV）。
- 两个应用、两台设备、两个 HBuilderX 版本（5.31 alpha、5.33 正式版）各崩一次。
- 故障线程的调用链完全一致：libjsruntime.so 在 NAPI 回收回调（ArkFinalizersPack::ProcessAll）里调 napi_delete_reference，访问了已失效的引用。
- AGC 因这一项把稳定性判为「不通过」，上架自检结论受影响。
和 https://ask.dcloud.net.cn/question/220578 应是同一类问题：那帖是 5.08，生产日志同样是 napi_delete_reference + ProcessAll。这里补充一条：5.31 和 5.33 打出的包里，libjsruntime.so 的 BuildID 相同（57311a36f57d40809ca82cc5027104a941920488），到 5.33 正式版这条路径仍会崩。
两次崩溃
| 应用 A | 应用 B | |
|---|---|---|
| 包名 / 版本 | com.zzyj.kingxiangqi 4.0.50 | com.chinaxueyun.xqwxt 3.0.4 |
| 编译器 | @dcloudio 3.0.0-5030320261023001（HBuilderX 5.33 正式版） | 3.0.0-alpha-5030120260930001（HBuilderX 5.31 alpha） |
| 鸿蒙运行时 | UniAppRuntime.har 5.32.2026101601（取自 HBuilderX 5.33 壳模板） | HBuilderX 5.31 壳模板自带 |
| 设备 / 系统 | HUAWEI Pura 90 Pro Max，6.1.0.135 | HUAWEI MateBook Pro（HAD-W24），6.1.0.135 |
| 进程存活 / 内存 | 3792 秒 / RSS 618MB，前台 | 1622 秒 / RSS 703MB，前台 |
| 崩溃前 | 自动测试反复 navigateTo / navigateBack，页面计数约 80，刚弹出加载框 | 在页面上点击并新开页面 |
故障线程栈（应用 A）
Reason:Signal:SIGSEGV(SEGV_MAPERR)@0x0052353331453000
LastFatalMessage:[NAPI] Crash occured on ProcessAll, callback: 388746328008
#00 pc 0000000000080308 /system/lib64/platformsdk/libace_napi.z.so(napi_delete_reference+24)
#01 pc 000000000006393c /data/storage/el1/bundle/libs/arm64/libjsruntime.so(57311a36f57d40809ca82cc5027104a941920488)
#02 pc 000000000005477c /system/lib64/platformsdk/libace_napi.z.so(ArkFinalizersPack::ProcessAll() const+108)
#03 pc 00000000000546d8 /system/lib64/platformsdk/libace_napi.z.so(ArkNativeEngine::RunCallbacks(ArkFinalizersPack*)+104)
#04 pc 0000000000054638 /system/lib64/platformsdk/libace_napi.z.so(ArkNativeEngine::PostFinalizeTasks()::$_8::__invoke(uv_work_s*, int)+24)
#05 pc 000000000001372c /system/lib64/platformsdk/libuv.so(uv__queue_done+228)应用 B 走的是同一条路径（libjsruntime.so pc 0x6383c → napi_delete_reference+88），随后在 ~ArkNativeEngine / GC 析构里崩在 libarkruntime。两份崩溃头都在附件里。
- 栈上没有应用自己的原生代码。
- 进程里非系统的 .so 只有 libjsruntime.so 和 libarkweb_engine.so。
- UTS 插件不在栈上。
诉求
- 请排查 libjsruntime.so 的 finalize 回调：是否会重复释放引用，或者在引擎、页面销毁之后才执行回调（竞态）。
- 应用侧有没有规避办法，比如限制页面栈深度？
- 华为上架自检据此判稳定性不通过，希望后续版本能带上修复。
完整的 cppcrash 日志（含崩溃前 HiLog）如有需要可以另外提供。
