HarmonyOS libuv.so崩溃

崩溃信息：

Generated by HiviewDFX@OpenHarmony  
  
Device info:MatePad Pro  
Build info:XYAO-W00 5.0.0.18(SP32DEVC00E18R1P1log)  
Fingerprint:ae6d8e7765ed1c2bcca6cdd861267e7f80c44ff46e0fbe43917a4de1d1c81d73  
Module name:com.xxx.xxx 
Version:1.0.2  
VersionCode:1000002  
PreInstalled:No  
Foreground:Yes  
Timestamp:2024-05-13 20:03:26.077  
Pid:xxx  
Uid:xxx  
Process name:com.xxx.xxx 
Process life cycle:5s  
Reason:Signal:SIGSEGV(SEGV_MAPERR)@0x0000000000000001  probably caused by NULL pointer dereference  
Fault thread info:  
  Tid:xxx, Name:.xxx.xxx 
#00 pc 0000000000017b14 /system/lib64/platformsdk/libuv.so(uv_run+724)(695211df6a3b75b52cec82e69c3c465b)  
#01 pc 000000000006c474 /system/lib64/platformsdk/libruntime.z.so(OHOS::AbilityRuntime::OHOSLoopHandler::OnTriggered()+156)(8bc0488a9cd7b4826476b535921cb6f9)  
#02 pc 000000000006ca04 /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)+48)(8bc0488a9cd7b4826476b535921cb6f9)  
#03 pc 0000000000013ca8 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventHandler::DistributeEvent(std::__h::unique_ptr<OHOS::AppExecFwk::InnerEvent, void (*)(OHOS::AppExecFwk::InnerEvent*)> const&)+940)(f056611c03a22ac39445298fd3e4fb94)  
#04 pc 0000000000020f78 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::(anonymous namespace)::EventRunnerImpl::Run()+764)(f056611c03a22ac39445298fd3e4fb94)  
#05 pc 0000000000023130 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventRunner::Run()+120)(f056611c03a22ac39445298fd3e4fb94)  
#06 pc 000000000007d630 /system/lib64/platformsdk/libappkit_native.z.so(OHOS::AppExecFwk::MainThread::Start()+740)(9573a3c6d6c74c2f9713f94df6f40517)  
#07 pc 0000000000013104 /system/bin/appspawn(RunChildProcessor+296)(fac2a838ca823d318e3ac6dd4513d837)  
#08 pc 0000000000038dfc /system/bin/appspawn(AppSpawnChild+284)(fac2a838ca823d318e3ac6dd4513d837)  
#09 pc 0000000000038c14 /system/bin/appspawn(AppSpawnProcessMsg+560)(fac2a838ca823d318e3ac6dd4513d837)  
#10 pc 00000000000338c8 /system/bin/appspawn(OnReceiveRequest+2380)(fac2a838ca823d318e3ac6dd4513d837)  
#11 pc 0000000000018300 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(HandleRecvMsg_+260)(95cad246ce0aaf53caac912e70808f04)  
#12 pc 0000000000017e80 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(HandleStreamEvent_+148)(95cad246ce0aaf53caac912e70808f04)  
#13 pc 0000000000015800 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(ProcessEvent+112)(95cad246ce0aaf53caac912e70808f04)  
#14 pc 0000000000015418 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(RunLoop_+308)(95cad246ce0aaf53caac912e70808f04)  
#15 pc 0000000000031b3c /system/bin/appspawn(AppSpawnRun+172)(fac2a838ca823d318e3ac6dd4513d837)  
#16 pc 0000000000020c80 /system/bin/appspawn(main+956)(fac2a838ca823d318e3ac6dd4513d837)  
#17 pc 00000000000a3118 /system/lib/ld-musl-aarch64.so.1(libc_start_main_stage2+64)(e7a78c0e604fec896ce7e6877f18ee4b)  
#18 pc 000000000001251c /system/bin/appspawn(_start_c+76)(fac2a838ca823d318e3ac6dd4513d837)

HarmonyOS

FengTianYa

2024-10-28 10:00:00

浏览

回答 1

待解决

回答 1

按赞同

按时间

put_get

关于libuv中的uv_close总结了一些正确和错误的写法供参考：

错误用法一：

将uv_handle_t句柄作为对象的成员变量，其生命周期与该对象一致。一旦调用了uv_close后，loop所在线程还未执行传入的回调函数，对象生命周期结束，则会crash。该crash是否必现需要看loop所在线程的业务繁忙程度。

class object {  
  public:  
    object() {  
  uv_xxx_init(loop, &handle, cb);  
}  
~object() {  
  // 该析构函数和loop所在线程执行的uv__run_closing_handles存在时序上的问题，会导致crash  
  uv_close((uv_handle_t*)&handle, nullptr);  
}  
private:  
  uv_xxx_t handle;  
}

该错误用法导致的崩溃信息一般有两个：

如果是非指针变量，崩溃信息通常都是空指针解引用。

如果是指针对象，崩溃有可能是空指针解引用，也有可能是一个被释放了的内存地址。

错误用法二：

在紧跟着uv_close之后进行内存释放。

uv_xxx_t* handle = nullptr;  
void func()  
{  
  handle = new uv_xxx_t;  
  uv_xxx_init(loop, handle, cb);  
  //业务逻辑  
  uv_close(handle, close_cb);  
  // 在此处释放handle，会导致时序问题，引起crash。  
  delete handle;  
}

Handles推荐写法：

深刻理解uv_close函数对您正确地管理handles生命周期至关重要。在使用uv的handles时，如果您不想使用开发文档中对handles的封装，下面是我们总结出来的正确写法，它可以保证您使用Handles的过程中不会出错（写法一、写法二尽管正确，但它并不是一个好的写法）。

写法一、用全局指针变量管理的Handles：

uv_xxx_t* handle = nullptr;  
  
void func()  
{  
  handle = new uv_xxx_t;  
  uv_xxx_init(loop, handle, cb);  
  // 业务逻辑  
  // 关闭  
  uv_close(handle, [](uv_handle_t* handle) {  
    // 传入的handle可能不是uv_handle_t类型的，因此进行强转成相应类型即可  
    delete (uv_xxx_t*)handle;  
  });  
}

写法二、通过全局变量管理的Handles：

这种写法尽管正确，但不建议该写法。

uv_xxx_t handle;  
  
void func()  
{  
  uv_xxx_init(loop, &handle, cb);  
  // 业务逻辑  
  // 关闭  
  uv_close(handle, nullptr);  
}

写法三、通过对象的成员变量进行管理的Handles：

通过动态分配内存申请的成员变量，可以在析构函数中调用uv_close，在传入的回调函数中delete它。

class object {  
  public:  
    object() {  
  handle = new uv_xxx_t;  
  uv_xxx_init(loop, handle, cb);  
}  
~object() {  
  uv_close(handle, [](uv_handle_t* handle) {  
    delete (uv_xxx_t*)handle;  
  });  
}  
private:  
  uv_xxx_t* handle;  
}

2024-10-28 15:54:39

如何写精华回答，获更多曝光？

发布

51CTO

51CTO博客

51CTO学堂

HarmonyOS libuv.so崩溃

订阅鸿蒙技术特刊，精选内容抢先看