HarmonyOS鸿蒙Next中app出现了很多OS_GC_Thread的crash，应该如何去定位原因呢？

HarmonyOS鸿蒙Next中app出现了很多OS_GC_Thread的crash，应该如何去定位原因呢？ 日志切片如下：

Process life time:18446744073709464720s
Reason:Signal:SIGABRT(SI_TKILL)@0x01317c2f00000f59 from:3929:20020271
Fault thread info:

Tid:4316, Name:OS_GC_Thread
#00 pc 000000000019ca00 /system/lib/ld-musl-aarch64.so.1(raise+228)(f77c0346c0084ebbadf721ea319f5f77)
#01 pc 0000000000149b70 /system/lib/ld-musl-aarch64.so.1(abort+20)(f77c0346c0084ebbadf721ea319f5f77)
#02 pc 0000000000003500 /system/lib64/chipset-pub-sdk/libclang_rt.ubsan_minimal.so(__ubsan_handle_load_invalid_value_minimal_abort+36)(e5be3d150d680ac145bcb484284d05894ef89f16)
#03 pc 0000000000382468 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::HashTrieMap::ClearNodeFromGC(panda::ecmascript::HashTrieMap::Indirect*, int, std::__h::function<panda::ecmascript::TaggedObject*(panda::ecmascript::TaggedObject*)> const&)+860)(0d69a79f2a5bf79a69fb024e1aa5e02f)
#04 pc 000000000038226c /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::HashTrieMap::ClearNodeFromGC(panda::ecmascript::HashTrieMap::Indirect*, int, std::__h::function<panda::ecmascript::TaggedObject*(panda::ecmascript::TaggedObject*)> const&)+352)(0d69a79f2a5bf79a69fb024e1aa5e02f)
#05 pc 00000000003822dc /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::HashTrieMap::ClearNodeFromGC(panda::ecmascript::HashTrieMap::Indirect*, int, std::__h::function<panda::ecmascript::TaggedObject*(panda::ecmascript::TaggedObject*)> const&)+464)(0d69a79f2a5bf79a69fb024e1aa5e02f)
#06 pc 0000000000382174 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::HashTrieMap::ClearNodeFromGC(panda::ecmascript::HashTrieMap::Indirect*, int, std::__h::function<panda::ecmascript::TaggedObject*(panda::ecmascript::TaggedObject*)> const&)+104)(0d69a79f2a5bf79a69fb024e1aa5e02f)
#07 pc 000000000037f008 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::EcmaStringTableCleaner::SweepWeakRefTask::Run(unsigned int)+92)(0d69a79f2a5bf79a69fb024e1aa5e02f)
#08 pc 000000000065ecc0 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::Runner::Run(unsigned int)+188)(0d69a79f2a5bf79a69fb024e1aa5e02f)
#09 pc 000000000065ed90 /system/lib64/platformsdk/libark_jsruntime.so(0d69a79f2a5bf79a69fb024e1aa5e02f)
#10 pc 00000000001bdcac /system/lib/ld-musl-aarch64.so.1(start+236)(f77c0346c0084ebbadf721ea319f5f77)

Registers:
x0:0000000000000000 x1:0000007ee6bbb600 x2:0000000000000000 x3:0000000000000008
x4:0000000000000010 x5:0000000000800000 x6:0000000000000010 x7:7f7f7f7f7f7f7f7f
x8:0000000000000087 x9:0000007ee6bbb9a8 x10:0000000009741d66 x11:0000000000016c58
x12:0000005bbedccf58 x13:0000005ce85f09a0 x14:0000005cedebb120 x15:82953b01fbc6a5fb
x16:0000005b26784bd0 x17:0000005b25d45b5c x18:0000000000000005 x19:0000000000000000
x20:0000005b26008000 x21:0000007ee6dc1140 x22:0000005bbf29fee8 x23:0000005bbf94ed50
x24:0000000000000003 x25:0000000000000001 x26:0000005cf2e42270 x27:0000007ee6bbb968
x28:0000005b26008000 x29:0000007ee6bbb680

lr:0000005b25d45b74 sp:0000007ee6bbb600 pc:0000005b25d98a00

更多关于HarmonyOS鸿蒙Next中app出现了很多OS_GC_Thread的crash，应该如何去定位原因呢？的实战教程也可以访问 https://www.itying.com/category-93-b0.html

3 回复

可以参考下这个问题：https://developer.huawei.com/consumer/cn/forum/topic/0203182626484795016?fid=0109140870620153026

更多关于HarmonyOS鸿蒙Next中app出现了很多OS_GC_Thread的crash，应该如何去定位原因呢？的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


在HarmonyOS Next中，OS_GC_Thread崩溃通常与内存管理相关。可通过以下步骤定位：

  1. 获取崩溃日志，重点关注GC线程的堆栈信息
  2. 检查内存使用情况，是否存在内存泄漏或过度分配
  3. 分析对象引用关系，查找可能的内存循环引用
  4. 检查是否频繁创建/销毁大对象

使用DevEco Studio的内存分析工具可辅助诊断。重点关注Native层内存操作（如C++代码）与ArkTS/ETS对象间的交互问题。

从日志来看，这是一个发生在GC线程(OS_GC_Thread)的crash，主要与JS运行时(ark_jsruntime)的内存管理相关。关键点分析：

  1. 崩溃发生在HashTrieMap::ClearNodeFromGC方法中，这是JS引擎的垃圾回收过程
  2. 错误类型是UBSAN检测到的无效值加载(__ubsan_handle_load_invalid_value_minimal_abort)，通常表示内存访问违规

建议排查方向：

  1. 检查应用中的JS代码是否存在内存泄漏或循环引用
  2. 检查是否在JS对象生命周期管理上有问题，如过早释放仍在使用的对象
  3. 检查是否有跨线程访问JS对象的情况
  4. 收集完整的hisysevent日志，查看崩溃前的内存使用情况

可以尝试使用DevEco Studio的内存分析工具来监控应用的内存使用情况，重点关注JS堆内存的变化趋势。

回到顶部