1 关键字

设备断连、DISCONNECTION、多次断连、一直断连

2 问题描述

环境： 产品： OpenHarmony版本号：OpenHarmony 3.2release 问题现象：使用Deveco Testing进行系统遍历测试，过程中设备出现断连，断连几次后就一直保持断连的状态，到第二天手动重启设备后，可再次连接上，DevEco Testing可继续进行重启前的测试。

3 问题原因

3.1 正常机制

正常情况下在用DevEco Testing进程压测时，设备不会断连，即使系统在某种情况下出现异常导致设备断连，按机制也会重新连接上，而不是一直保持断连状态。

3.2 异常机制

内存严重不足时，导致pipe中数据出错，然后导致会话结束。而守护进程检查到会话结束后会去重新建立连接，但由于内存严重不足导致新任务申请不到内存，无法建立连接，导致断连。

4 解决方案

将各模块内存泄漏相关的修改合入此版本的代码中，编译烧录新版本，未再复现此问题。

5 定位过程

1. 查看出现DISCONNECTION问题的时间和现象，首次断连出现在18:41，断连几次后，在18:46最后一次断连后就一直没连上，直到第二天9:46手动断电重启设备（REBOOT），才再次连接上设备。

2. 查看抓取的kmsg log，找到附近时间点的日志，和对应代码，可发现WritePid函数出错，原因是fd未成功打开 

3. 查看hdc.log文件附近日志，可发现nread读取出错（函pid相关数据），会话重置，"restart daemon" ；和kmsg中附近时间点hdcd启动成功，打开fd失败的日志相对应。

 

4. 对比其他时间点的DISCONNECTION报错，虽也有nread失败，但后续又恢复了连接，且未出现fd打开失败的问题。

5. 查看附近hilog日志，有很多低内存打印、多次文件打开失败和杀进程；基本判断是由于低内存引起的系统异常，导致的DISCONNECTION

6. 将内存泄漏相关修改合入此版本代码，编译新版本测试，此问题消失，内存泄漏相关的提交有多个模块的多次提交，如： 

https://gitee.com/openharmony/third_party_flutter/pulls/276
https://gitee.com/openharmony/arkui_ace_engine/pulls/10721
https://gitee.com/openharmony/graphic_graphic_2d/pulls/4299
https://gitee.com/openharmony/distributeddatamgr_relational_store/pulls/364
https://gitee.com/openharmony/window_window_manager/pulls/2384
https://gitee.com/openharmony/ability_ability_runtime/pulls/5130
https://gitee.com/openharmony/arkui_ace_engine/pulls/12793
https://gitee.com/openharmony/arkui_ace_engine/pulls/12777
https://gitee.com/openharmony/arkui_ace_engine/pulls/12081
https://gitee.com/openharmony/systemabilitymgr_samgr/pulls/495
https://gitee.com/openharmony/inputmethod_imf/pulls/709
https://gitee.com/openharmony/window_window_manager/pulls/2507
... ...

6 知识分享

hdc.log的获取：设备中hdc的log在/data/local/tmp/下，但有时并不能及时获取到这个log（被新log覆盖掉了），而hdc.log.0文件保存的hdc的log时间跨度较长，若没有有效的hdc.log，可以从hdc.log.0文件获取相关时段的日志