HarmonyOS 鸿蒙Next buffer.Blob 崩溃 THREAD_BLOCK_6S

发布于 1周前 作者 songsunli 最后一次编辑是 5天前 来自 鸿蒙OS

HarmonyOS 鸿蒙Next buffer.Blob 崩溃 THREAD_BLOCK_6S

偶现的线上崩溃

在函数最外层调用了try catch,但是看起来并没有生效。

从堆栈上看应该是Blob初始化有问题,不知道为啥最后提示THREAD_BLOCK_6S,是触发了鸿蒙什么多线程安全检测吗?

PS: 堆栈上因为现在还没做符号表解析,只展示了ts的代码行数,跟实际ets有点对不上?有什么办法将我本地的ets代码转为ts,跟堆栈行数对齐进一步定位具体代码报错位置吗?
 

#00 pc 00000000000a432c /system/lib/ld-musl-aarch64.so.1(ec44c498ff1525a6f5d1a1a23c105a8b)

#01 pc 00000000006e9ec4 /system/lib64/platformsdk/libark_jsruntime.so(panda::os::thread::GetCurrentThreadId()+12)(a3d1ba664de66d31faed07d711ee1299)

#02 pc 000000000064e96c /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::Taskpool::IsDaemonThreadOrInThreadPool(std::h::thread_id) const+112)(a3d1ba664de66d31faed07d711ee1299)

#03 pc 00000000003853f4 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::EcmaVM::CheckThread() const+68)(a3d1ba664de66d31faed07d711ee1299)

#04 pc 00000000005b8100 /system/lib64/platformsdk/libark_jsruntime.so(panda::TryCatch::HasCaught() const+88)(a3d1ba664de66d31faed07d711ee1299)

#05 pc 0000000000058aa8 /system/lib64/platformsdk/libace_napi.z.so(napi_get_element+216)(dc293a22b36a4db17dc689ff9413b64e)

#06 pc 000000000000beac /system/lib64/module/libbuffer.z.so(OHOS::buffer::GetArray(napi_env*, napi_value)+228)(4f3e0ffb96a978e8250dfbbcd826e32f)

#07 pc 000000000000bc68 /system/lib64/module/libbuffer.z.so(OHOS::buffer::BlobConstructor(napi_env__, napi_callback_info__) (.cfi)+172)(4f3e0ffb96a978e8250dfbbcd826e32f)

#08 pc 000000000003cdc8 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo)+216)(dc293a22b36a4db17dc689ff9413b64e)

#09 pc 00000000003f4cf8 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallNewAndDispatchNative+136)

#10 at Blob (/usr1/hmos_for_system/src/increment/sourcecode/out/generic_generic_arm_64only/general_all_phone_standard/obj/commonlibrary/ets_utils/js_api_module/buffer/js_buffer.js:287:1)

#11 at buildBodyContentArrayBuffer (entry|@xxxx/main/ets/HttpRequest.ts:52:1)

#12 at uploadFileHttp (entry|@xxx/main/ets/HttpRequest.ts:124:1)

#13 at q843 (entry|@xxxx/main/ets/HttpRequest.ts:164:1)

#14 pc 00000000003a3020 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::InterpreterAssembly::Execute(panda::ecmascript::EcmaRuntimeCallInfo*)+216)(a3d1ba664de66d31faed07d711ee1299)

#15 pc 00000000005a2084 /system/lib64/platformsdk/libark_jsruntime.so(panda::FunctionRef::CallForNapi(panda::ecmascript::EcmaVM const*, panda::JSValueRef*, panda::JSValueRef* const*, int)+324)(a3d1ba664de66d31faed07d711ee1299)

#16 pc 0000000000059564 /system/lib64/platformsdk/libace_napi.z.so(napi_call_function+308)(dc293a22b36a4db17dc689ff9413b64e)

#17 pc 0000000000009d20 /system/lib64/platformsdk/libtimer.z.so(OHOS::JsSysModule::Timer::TimerCallback(uv_timer_s*) (.cfi)+260)(024cf0bae79814a3a5d968e809f85425)

#18 pc 00000000000136ac /system/lib64/platformsdk/libuv.so(uv__run_timers+52)(33523426de3d48909d73f2eafe1a6c41)

#19 pc 0000000000016edc /system/lib64/platformsdk/libuv.so(uv_run+268)(33523426de3d48909d73f2eafe1a6c41)

#20 pc 000000000007cd8c /system/lib64/platformsdk/libruntime.z.so(OHOS::AbilityRuntime::OHOSLoopHandler::OnTriggered()+140)(47bb52515db7f21ca4db76c2d2d70779)

#21 pc 000000000007d338 /system/lib64/platformsdk/libruntime.z.so(std::__h::__function::__func<OHOS::AbilityRuntime::OHOSLoopHandler::OnTriggered()::$_0, std::__h::allocator<OHOS::AbilityRuntime::OHOSLoopHandler::OnTriggered()::$_0>, void ()>::operator()() (.9efded9864dc55830f61b3b92d59beab)+52)(47bb52515db7f21ca4db76c2d2d70779)

#22 pc 000000000001bdb4 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventHandler::DistributeEvent(std::_h::unique_ptr<OHOS::AppExecFwk::InnerEvent, void ()(OHOS::AppExecFwk::InnerEvent)> const&)+1140)(f560fd919e62c611875d16157ed12432)

#23 pc 000000000002d6a8 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::(anonymous namespace)::EventRunnerImpl::ExecuteEventHandler(std::h::unique_ptr<OHOS::AppExecFwk::InnerEvent, void ()(OHOS::AppExecFwk::InnerEvent)>&)+348)(f560fd919e62c611875d16157ed12432)

#24 pc 000000000002cf64 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::(anonymous namespace)::EventRunnerImpl::Run()+908)(f560fd919e62c611875d16157ed12432)

#25 pc 0000000000030308 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventRunner::Run()+528)(f560fd919e62c611875d16157ed12432)

#26 pc 00000000000aebb4 /system/lib64/platformsdk/libappkit_native.z.so(OHOS::AppExecFwk::MainThread::Start()+400)(609ed26bb19fdef3802b5e11bcdcbe00)

#27 pc 0000000000004e34 /system/lib64/appspawn/appspawn/libappspawn_ace.z.so(RunChildProcessor(AppSpawnContent*, AppSpawnClient*)+568)(fb19444fe406bd4b1f49564af1389d8f)

#28 pc 000000000000b9e4 /system/bin/appspawn(AppSpawnChild+576)(bab4a649871ef963538742f1ebbbbb80)

#29 pc 00000000000150e8 /system/bin/appspawn(ProcessSpawnReqMsg+2956)(bab4a649871ef963538742f1ebbbbb80)

#30 pc 0000000000013360 /system/bin/appspawn(OnReceiveRequest+132)(bab4a649871ef963538742f1ebbbbb80)

#31 pc 0000000000016cd0 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(HandleRecvMsg+344)(45236bc4e277c34897d485345eb2729e)

#32 pc 00000000000167a4 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(HandleStreamEvent+192)(45236bc4e277c34897d485345eb2729e)

#33 pc 0000000000013e84 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(ProcessEvent+88)(45236bc4e277c34897d485345eb2729e)

#34 pc 0000000000013a40 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(RunLoop+308)(45236bc4e277c34897d485345eb2729e)

#35 pc 00000000000112d0 /system/bin/appspawn(AppSpawnRun+136)(bab4a649871ef963538742f1ebbbbb80)

#36 pc 000000000000ec3c /system/bin/appspawn(main+764)(bab4a649871ef963538742f1ebbbbb80)

#37 pc 00000000000a1078 /system/lib/ld-musl-aarch64.so.1(libc_start_main_stage2+64)(ec44c498ff1525a6f5d1a1a23c105a8b)

const buildBodyContentArrayBuffer =
  async (boundary: string, fileName: string, content: ArrayBuffer): Promise<ArrayBuffer> => {
    let body = `--${boundary}\r\n`
    body = body + `Content-Disposition: form-data; name="file"; filename="${fileName}"\r\n`
    body = body + `Content-Type: application/octet-stream; charset=utf-8\r\n`
    body = body + '\r\n'
    const bodyBuff = buffer.from(body)

    let bodyEnd = '\r\n'
    bodyEnd = bodyEnd + `--${boundary}`
    bodyEnd = bodyEnd + '--\r\n'
    const bodyEndBuff = buffer.from(bodyEnd)

    let blob: buffer.Blob = new buffer.Blob([bodyBuff.buffer, content, bodyEndBuff.buffer])
    return blob.arrayBuffer()
  }
3 回复

您好!看了下报错堆栈,是由于js_buffer.js:287行引出的错误?

可以提供下 js_buffer.js 这个文件吗?

#10 at Blob (/usr1/hmos_for_system/src/increment/sourcecode/out/generic_generic_arm_64only/general_all_phone_standard/obj/commonlibrary/ets_utils/js_api_module/buffer/js_buffer.js:287:1)

THREAD_BLOCK_6S的报错信息是:应用主线程卡死超时,看下是否有异常操作,占用主线程?

这个应该是官方的底层库,new buffer.Blob([bodyBuff.buffer, content, bodyEndBuff.buffer]) 这行代码底层逻辑吧,用了js的buffer库。但是我都找不到这些官方库存放的地方,编译器鼠标左键跳转,只能跳到buffer的声明

针对您提到的HarmonyOS鸿蒙系统中Next buffer.Blob崩溃,并出现THREAD_BLOCK_6S错误的问题,这通常涉及到系统资源管理或内存访问异常。以下是一些可能的原因分析:

  1. 内存泄漏:长时间运行的应用可能导致内存泄漏,当系统尝试访问已释放或损坏的内存块时,可能会触发此类崩溃。

  2. 多线程冲突:如果多个线程同时访问或修改同一内存区域(如Blob对象),而未进行适当的同步处理,可能会导致数据不一致或崩溃。

  3. 驱动或系统bug:鸿蒙系统的某些组件或驱动程序可能存在缺陷,导致在处理特定类型的内存操作时崩溃。

  4. 硬件兼容性:在某些设备上,由于硬件差异或兼容性问题,也可能导致特定的系统错误。

为了解决这个问题,建议首先检查应用的内存使用情况和线程管理,确保没有内存泄漏和多线程冲突。同时,确保您的鸿蒙系统版本是最新的,因为系统更新可能包含对此类问题的修复。

如果问题依旧没法解决请联系官网客服,官网地址是:https://www.itying.com/category-93-b0.html

回到顶部