1# Analyzing App Freeze 2 3Appfreeze occurs when an application does not respond a click event within a certain period of time. OpenHarmony provides a mechanism for detecting appfreeze and generates appfreeze logs for fault analysis. 4 5> **NOTE** 6> This guide applies only to applications in the stage model. Before using this guide, you must have basic knowledge about the JS applications, C++ program stacks, and application-related subsystems. 7 8## AppFreeze Detection 9 10Currently, appfreeze detection supports the fault types listed in the following table. 11 12| Fault| Description| 13| -------- | -------- | 14| THREAD_BLOCK_6S | The application main thread times out.| 15| APP_INPUT_BLOCK | The user input response times out.| 16| LIFECYCLE_TIMEOUT | Ability lifecycle switching times out.| 17 18### Application Main Thread Timeout 19 20This fault indicates that the main thread of this application is suspended or too many tasks are executed, which affects task execution smoothness and experience. 21 22Such a fault can be detected as follows: The watchdog thread of the application periodically inserts an activation detection to the main thread and inserts a timeout reporting mechanism to its own thread. If the activation detection is not executed within 3 seconds, the **THREAD_BLOCK_3S** event is reported. If the activation detection is not executed within 6 seconds, the **THREAD_BLOCK_6S** event is reported. The two events together form an appfreeze log. 23 24The following figure shows the working principle. 25 26 27 28### User Input Response Timeout 29 30This fault occurs when the system does not respond to a click event within 5 seconds. 31 32Such a fault can be detected as follows: When a user clicks a button of the application, the input system sends a click event to the application. If the input system does not receive a response from the application within 5 seconds, a fault event is reported. 33 34The following figure shows the working principle. 35 36 37 38### Lifecycle Switching Timeout 39 40Lifecycle switching timeout refers to an [UIAbility Lifecycle](../application-models/uiability-lifecycle.md#uiability-lifecycle) switching timeout or a [PageAbility Lifecycle](../application-models/pageability-lifecycle.md#pageability-lifecycle) switching timeout. 41 42The fault occurs during lifecycle switching and affects Ability switching and PageAbility switching of the application. 43 44Such a fault can be detected as follows: Upon the start of a lifecycle switching process, the main thread inserts a timeout task to the watchdog thread, and then removes the timeout task when the lifecycle switching is complete. If the timeout task is not removed within a specific time frame, a fault event is reported. 45 46The lifecycle switching timeout events consist of **LIFECYCLE_HALF_TIMEOUT** and **LIFECYCLE_TIMEOUT**. **LIFECYCLE_HALF_TIMEOUT** is used as the warning event of **LIFECYCLE_TIMEOUT** to capture the Binder information. 47 48 49 50The timeout duration varies according to the lifecycle. 51 52| Lifecycle| Timeout Duration| 53| -------- | -------- | 54| Load | 10s | 55| Terminate | 10s | 56| Connect | 3s | 57| Disconnect | 0.5s | 58| Foreground | 5s | 59| Background | 3s | 60 61## AppFreeze Log Analysis 62 63To identify the cause of appfreeze, analyze the appfreeze logs together with HiLog logs. 64 65The following example shows an appfreeze log analysis. You can analyze the fault based on actual situation. 66 67Appfreeze logs consist of header information, and general and specific information in the body. 68 69### Header Information 70 71| Field| Description| 72| -------- | -------- | 73| Reason | Reason why the application does not respond. For details, see [appfreeze Detection](#appfreeze-detection).| 74| PID | PID of the failed process, which can be used to search for related process information in the Hilog logs.| 75| PACKAGE_NAME | Application package name.| 76 77``` 78============================================================ 79Device info:OpenHarmony 3.2 80Build info:OpenHarmony 4.0.5.3 81Module name:com.xxx.xxx 82Version:1.0.0 83Pid:1561 84Uid:20010039 85Reason:LIFECYCLE_TIMEOUT 86sysfreeze: LIFECYCLE_TIMEOUT LIFECYCLE_TIMEOUT at 20230317170653 87>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 88DOMAIN:AAFWK 89STRINGID:LIFECYCLE_TIMEOUT 90TIMESTAMP:2023/XX/XX/XX-XX:XX:XX:XX 91PID:1561 92UID:20010039 93PACKAGE_NAME:com.xxx.xxx 94PROCESS_NAME:com.xxx.xxx 95MSG:ablity:EntryAbility background timeout 96``` 97 98### General Information in the Log Body 99 100General information is present in all the aforementioned logs. It contains the fields listed in the following table. You can search for these fields to locate the related information in the log. 101 102| Field| Description| 103| -------- | -------- | 104| EVENTNAME | One or more fault events that constitute the cause of main thread freeze event.| 105| TIMESTAMP | Time when the fault event reported. You can narrow down the time range to view HiLog logs based on the timeout duration described in [AppFreeze Detection](#appfreeze-detection).| 106| PID | PID of the failed process, which can be used with the timestamp and timeout duration to search for related process information in the Hilog logs.| 107| PACKAGE_NAME | Application package name.| 108| MSG | Dump information or description of the fault.| 109| BinderCatcher | Information about IPC calls between a process and other system processes, such as the call waiting time.| 110| PeerBinder Stacktrace | Information about stack trace of the peer process.| 111| cpuusage | CPU usage of the device.| 112| memory | Memory usage of the process.| 113 114The **MSG** field includes the cause of the freeze event and task information in the main thread queue of the application. 115 116The task information in the main thread queue includes: 117 118- The running task and its start time. If the task start time is much earlier than the log report time, the running task causes the freeze event. 119 120- Historical task time. If a new task cannot respond in time, you can check whether there are too many historical tasks based on historical task time. 121 122- Tasks that are not executed in the stack. 123 124**Example of the calling process stack:** 125 126Locate the application stack information by searching for the **PID**. In the following stack, the window stays in the IPC communication phase when it sends events to the system through the IPC. 127 128``` 129OpenStacktraceCatcher -pid==1561 packageName is com.ohos.huawei.myapplication 130Result: 0 ( no error ) 131Timestamp:2017-08-0817:06:53.000 132Pid:1561 133Uid:20010039 134Process name:com.ohos.huawei.myapplication 135Tid:1561,Name:i.myapplication 136#00 pc 0017888c /system/lib/libark_jsruntime.so 137#01 pc 00025779 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderConnector:WriteBinder(unsigned Long,void*)+56) 138#02 pc 000265a5 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:TransactWithDriver(bool)+216) 139#03 pc 0002666f /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:StartWorkLoop()+18) 140#04 pc 000270a9 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:JoinThread(bool)+32) 141#05 pc 00023783 /system/lib/platformsdk/libipc_core.z.so(OHOS:IPCWorkThread:ThreadHandler(void*)+290) 142#06 pc 00e1c6f7 /system/lib/libace.z.so 143#07 pc 0091bbdd /system/lib/libace.z.so 144#08 pc 0092fd9d /system/lib/libace.z.so 145#09 pc 0092fa5f /system/lib/libace.z.so 146#10 pc 0092cd6b /system/lib/libace.z.so 147#11 pc 009326a9 /system/lib/libace.z.so 148#12 pc 0093054b /system/lib/libace.z.so 149#13 pc 009324f3 /system/lib/libace.z.so 150#14 pc 003989e1 /system/lib/libace.z.so 151#15 pc 0045dd4b /system/lib/libace.z.so 152#16 pc 00d24fef /system/lib/libace.z.so 153#17 pc 0041e6e9 /system/lib/libace.z.so 154#18 pc 0000b4d9 /system/lib/platformsdk/libeventhandler.z.so(OHOS:AppExecFwk:EventHandler:DistributeEvent(std::__h:unique_ptr<0 #19 pc 00012829 /system/lib/platformsdk/libeventhandler.z.so 155#20 pc 00011841 /system/lib/platformsdk/libeventhandler.z.so(OHOS:AppExecFwk:EventRunner:Run()+64) 156#21 pc 00054a8b /system/lib/libappkit_native.z.so(OHOS:AppExecFwk:MainThread:Start()+278) 157#22 pc 00011503 /system/bin/appspawn 158#23 pc 0001141f /system/bin/appspawn 159#24 pc 0000ee97 /system/bin/appspawn 160``` 161 162**Example of BinderCatcher information**: 163 164Search for the **PID** to find out the process with which this process communicates and the waiting duration of the synchronous communication. 165 166In the following example, process **1561** sends an IPC request to process **685** but does not receive any response within 10 seconds. 167 168``` 169PeerBinderCatcher -pid==1561 Layer_==0 170 171 172BinderCatcher -- 173 1561::1561t0685:0c0de0Wait:10.366245919s 1329::1376t0487:794c0de0Wait:0.12070041s 174 175pid context request started max ready free_async_space 1761561 binder 0 3 16 4 520192 177544 binder 0 4 16 5 520192 1781104 binder 0 1 16 2 520192 1791397 binder 0 1 16 3 520192 180... 181``` 182 183**Example of PeerBinder Stacktrace information**: 184 185The following example shows the stack information of process **685**, which is suspended at the peer end. 186 187``` 188PeerBinder Stacktrace -- 189 190PeerBinderCatcher start catcher stacktrace for pid 685 191Result: 0 ( no error ) 192Timestamp:2017-08-0817:06:55.000 193Pid:685 194Uid:1000 195Process name:wifi_manager_service 196Tid:658,Name:wifi_manager_service 197#00 pc 000669f0 /system/lib/ld-musl-arm.so.1 198#01 pc 000c60cc /system/lib/ld-musl-arm.so.1 199#02 pc 000c5040 /system/lib/ld-musl-arm.so.1 200#03 pc 000c6818 /system/lib/ld-musl-arm.so.1(__pthread_cond_timedwait_time64+596) 201#04 pc 000bd058 /system/lib/libc++.so 202#05 pc 0008592c /system/lib/ld-musl-arm.so.1(ioctl+72) 203#06 pc 00025779 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderConnector:WriteBinder(unsigned long,void*)+56) 204#07 pc 000265a5 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:TransactWithDriver(bool)+216) 205#08 pc 0002666f /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:StartWorkLoop()+18) 206#09 pc 000270a9 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderInvoker:JoinThread(bool)+32) 207#10 pc 00023783 /system/lib/platformsdk/libipc_core.z.so(OHOS:IPCWorkThread:ThreadHandler(void*)+290) 208#11 pc 0007b4d9 /system/lib/platformsdk/libeventhandler.z.so(OHOS:AppExecFwk:EventHandler:DistributeEvent(std::__h:unique_ptr<OHOS:Ap 209#12 pc 00072829 /system/lib/platformsdk/libeventhandler.z.so 210#13 pc 00071841 /system/lib/platformsdk/libeventhandler.z.so(OHOS:AppExecFwk:EventRunner:Run()+64) 211#14 pc 00094a8b /system/lib/libappkit_native.z.so(OHOS:AppExecFwk:MainThread:Start()+278) 212 213Tid:1563,Name:IPC_0_1563 214#00 pc 0009392c /system/lib/ld-musl-arm.so.1(ioctl+72) 215#01 pc 00025779 /system/lib/platformsdk/libipc_core.z.so(OHOS:BinderConnector:WriteBinder(unsigned long,void*)+56) 216``` 217 218**Example of CPU usage information**: 219 220The following example shows the CPU usage information of the device. 221 222``` 223Load average:2.87 /1.45 /0.58;the cpu load average in 1 min,5 min and 15 min 224CPU usage fr0m2023-03-1017:06:53t02023-03-1017:06:53 225Total:29%;User Space:28%;Kernel Space:1%;iowait:6%;irq:0%;idle:62% 226Details of Processes: 227 PID Total Usage User Space Kernel Space Page Fault Minor Page Fault Major Name 228 1561 23% 23% 0% 9985 26 i.myapplication 229 527 1% 1% 0% 3046 9 hidumper_servic 230 242 1% 1% 0% 69799 280 hiview 231``` 232 233**Example of memory usage information**: 234 235The following example shows the memory usage information of the process. 236 237``` 238-------------------------------------------[memory]---------------------------------------- 239 Pss Shared Shared Private Private Swap SwapPss Heap Heap 240 Total CLean Dirty CLean Dirty Total Total Size Alloc 241 (kB) (kB) (kB) (kB) (kB) (kB) (kB) (kB) (kB) 242------------------------------------------------------------------------------------------- 243guard 0 0 0 0 0 0 0 0 0 244native heap 185 0 180 0 160 0 0 0 0 245AnonPage other 17881 12 12376 88 15948 0 0 0 0 246stack 292 0 0 0 292 0 0 0 0 247.S0 5053 63408 4172 1812 2640 0 0 0 0 248.ttf 1133 3092 0 4 0 0 0 0 0 249dev 10 0 108 8 0 0 0 0 0 250FilePage other 121 556 8 0 4 0 0 0 0 251------------------------------------------------------------------------------------------ 252Total 34675 67068 16844 1912 19044 0 0 0 0 253``` 254 255### Specific Information in the Log Body (Application Main Thread Timeout) 256 257The value of **Reason** is **THREAD_BLOCK_6S**. According to [Application Main Thread Timeout](#application-main-thread-timeout), **THREAD_BLOCK** consists of **THREAD_BLOCK_3S** and **THREAD_BLOCK_6S**. By comparing the two parts, you can determine whether the appfreeze is due to a suspension or excessive tasks. 258 259**THREAD\_BLOCK\_3S** is followed by **THREAD\_BLOCK\_6S** in the log. You can search for **EVENTNAME** to locate the two events in the log. 260 261Both events contain the **MSG** field, which stores information about the processing queue of the main thread when the fault occurs. Hence, you can view the status of the event processing queue of the main thread at the two time points. 262 263The example log shows that the event that started at **05:06:18.145** in the low-priority queue is running, and it is displayed in both the **THREAD_BLOCK_3S** and **THREAD_BLOCK_6S** logs. This indicates that the main thread suspension is not caused by excessive tasks. 264 265Because **THREAD_BLOCK_6S** indicates a main thread suspension, you only need to analyze the stack information of the main thread (the ID of the main thread is the same as the process ID). In the example log, the main thread stack is run in the JS through ArkUI and therefore it can be concluded that the suspension occurs in the JS. Both **3S** and **6S** are stacks in this position, indicating that the JS is suspended. However, the cause is not that there are too many tasks. 266 267THREAD_BLOCK_3S: 268 269``` 270start time:2017/08/08-17:06:24:380 271DOMAIN = AAFWK EVENTNAME THREAD_BLOCK_3S 272TIMESTAMP = 2017/08/08-17:06:24:363 273PID = 1561 274UID = 20010039 275TID = 1566 276PACKAGE_NAME com.ohos.huawei.myapplication 277PROCESS_NAME com.ohos.huawei.myapplication 278eventLog_action pb:1 eventLog_interval 10 279MSG = App main thread is not response!EventHandler dump begin curTime:2017-08-08 05:06:24.362 280 Event runner (Thread name =Thread ID 1561)is running 281 Current Running:start at 2017-08-08 05:06:18.145,Event send thread 1561,send time =2017-08-08 05:06:18.145,handle time =2017-08-08 05: 282 Immediate priority event queue information: 283 Total size of Immediate events 0 284 High priority event queue information: 285 No.1 Event send thread 1561,send time 2017-08-08 05:06:18.039,handle time 2017-08-08 05:06:21.539,task name [anr_handler.cpp(Send Total size of High events 1 286 Low priority event queue information: 287 No.1:Event{send thread=1566,send time=2017-08-0805:06:21.062,handle time=2017-08-0805:06:21.062,id=1} 288 Total size of Low events 1 289 Idle priority event queue information: 290 Total size of Idle events 0 291 Total event size :2 292 293 Timestamp: 2017-08-0817:06:24.4142447784 294 Pid: 1561 295 Uid: 20010039 296 Process name: com.ohos.huawei.myapplication 297 Tid:1561 Name:i.myapplication 298 at anonymous (D:/project/OpenHarmonyOS/MyApplication_test/entry/build/default/intermediates/loader_out/default/ets,pages/Index_.js:0:1) 299 #00 pc 0017909c /system/lib/libark_jsruntime.so 300 #01 pc 00177ebb /system/lib/libark_jsruntime.so 301 #02 pc 0024b4bb /system/lib/libark_jsruntime.so(panda:FunctionRef:Call(panda:ecmascript:EcmaVM const*,panda:Local<panda:JSValueRef>,panda 302 #03 pc 00fbed23 /system/lib/libace.z.so 303 #04 pc 00d8208f /system/lib/libace.z.so 304 ... 305``` 306 307THREAD_BLOCK_6S: 308``` 309start time: 2017/08/08-17:06:27:299 310DOMAIN = AAFWK 311EVENTNAME THREAD_BLOCK_6S 312TIMESTAMP = 2017/08/08-17:06:27:292 313PID = 1561 314UID = 20010039 315TID = 1566 316PACKAGE_NAME com.ohos.huawei.myapplication 317PROCESS NAME com.ohos.huawei.myapplication eventLog_action cmd:c,cmd:m,tr,k:SysRqFile 318eventLog_interval 10 319MSG = App main thread is not response!EventHandler dump begin curTime:2017-08-08 05:06:27.291 320 Event runner (Thread name =Thread ID =1561)is running 321 Current Running:start at 2017-08-08 05:06:18.144, Event {send thread 1561,send time =2017-08-08 05:06:18.145,handle time =2017-08-08 05: 322 Immediate priority event queue information: 323 Total size of Immediate events 0 324 High priority event queue information: 325 No.1 Event send thread 1561,send time 2017-08-08 05:06:18.039,handle time 2017-08-08 05:06:21.539,task name [arr_handler.cpp(Se Total size of High events 1 326 Low priority event queue information: 327 No.1:Event{send thread=1566,send time=2017-08-0805:06:21.062,handle time=2017-08-0805:06:21.062,id=1} 328 No.2 Event send thread 1566,send time 2017-08-08 05:06:24.369,handle time 2017-08-08 05:06:24.369,id =1 329 Total size of Low events 2 330 Idle priority event queue information: 331 Total size of Idle events 0 332 Total event size 3 333 334Timestamp:2017-08-0817:0k:27,4142447784 335Pid:1561 336Uid:20010039 337Process name:com.ohos.huawei.myapplication 338Tid:1561 Name:i.myapplication 339 at anonymous (D:/project/OpenHarmony0S/MyApplication_test/entry/build/default/intermediates/loader_out/default/ets/pages/Index_.js:0:1) 340 #00 pc 00178dcc /system/lib/libark_jsruntime.so 341 #01 pc 00177ebb /system/lib/libark_jsruntime.so 342 #02 pc 0024b4bb /system/lib/libark_jsruntime.so(panda:FunctionRef:Call(panda:ecmascript:EcmaVM const*,panda:Local<panda:JSValueRef>,par 343 #03 pc 00fbed23 /system/lib/libace.z.so 344 #04 pc 00d8208f /system/lib/libace.z.so 345 #05 pc 00d7af1b /system/lib/libace.z.so 346``` 347 348Check the code being executed on the application side based on the Hilog log. 349 350Generally, you can view the [General Information in the Log Body](#general-information-in-the-log-body) to determine the cause of an appfreeze event, including peer communication suspension, high CPU usage, memory leakage, or a large amount of memory. 351 352### Specific Information in the Log Body (User Input Response Timeout) 353 354The value of **Reason** is **APP_INPUT_BLOCK**, indicating that no response is received within 5 seconds after a click event. 355 356You can find the event description in **MSG**. 357 358For details, see [General Information in the Log Body](#general-information-in-the-log-body). Note that there is a high probability that the main thread is suspended in the case of no response to the user input. You can compare the stack and BinderCatcher information in two logs for further analysis. If there is no main thread suspended, it may indicates that there is a large number of other events before the input event. This may not cause a main thread suspension but can probably result in no response to user input. 359 360### Specific Information in the Log Body (Lifecycle Switching Timeout) 361 362Similar to **THREAD_BLOCK**, **LIFECYCLE_TIMEOUT** consists of two parts, namely **LIFECYCLE_HALF_TIMEOUT** and **LIFECYCLE_TIMEOUT**. 363 364**MSG** indicates the lifecycle that encounters a timeout. 365 366In the following example, **LIFECYCLE_TIMEOUT** indicates that the process times out when **Ability** is switched to background. You can find Hilog information based on the timeout duration of [Lifecycle Switching Timeout](#lifecycle-switching-timeout). 367 368LIFECYCLE_TIMEOUT: 369 370``` 371DOMAIN:AAFWK 372STRINGID:LIFECYCLE 373TIMEOUT TIMESTAMP:2023/03/10-17:06:53:65 374PID:1561 375UID:20010039 376PACKAGE_NAME:com.ohos.huawei.myapplication 377PROCESS_NAME:com.ohos.huawei.myapplication 378MSG:ability:EntryAbility background timeout 379``` 380 381For details about other log information, see [General Information in the Log Body](#general-information-in-the-log-body). Note that there is a high probability that the main thread is suspended during lifecycle switching. You can compare the stack and BinderCatcher information in two logs for further analysis. 382 383## Application Exit 384 385If any of the following faults occurs on an application, the application will be killed to ensure that the application can be recovered: 386 387| Fault| Description| 388| -------- | -------- | 389| THREAD_BLOCK_6S | The application main thread times out.| 390| APP_INPUT_BLOCK | The user input response times out.| 391| LIFECYCLE_TIMEOUT | Ability lifecycle switching times out.| 392 393## Fault Analysis 394 395To locate an appfreeze event, you need to obtain related logs such as fault logs, hilog logs, and trace logs. 396 397### Obtaining the Log 398 399The appfreeze log is managed together with the native process crash, JS application crash, and system process crash logs in the FaultLogger module. You can obtain the log in any of the following ways. 400 401- Method 1: DevEco Studio 402 403 DevEco Studio collects device fault logs and saves them to **FaultLog**. For details, see <!--RP1-->[DevEco Studio User Guide-FaultLog](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/ide-fault-log-V5)<!--RP1End-->. 404 405- Method 2: hiAppEvent APIs 406 407 hiAppEvent provides APIs to subscribe to various fault information. For details, see [Introduction to HiAppEvent](hiappevent-intro.md). 408 409<!--Del--> 410- Method 3: Shell 411 412 AppFreeze logs are stored in the device-specific **/data/log/faultlog/faultlogger/** directory. The log files are named in the format of **appfreeze-application package name-application UID-time (seconds)**. 413 414  415<!--DelEnd--> 416 417### Confirming Basic Information 418 419#### Obtain basic information such as the process ID of the freeze application and whether the application is in the foreground 420 421``` 422Generated by HiviewDFX@OpenHarmony 423============================================================ 424Device info:HUANEI Mate 60 Pro 425Build info:ALN-AL00 x.x.x.xx(XXXXXXX) 426Fingerprint: ef8bd28f8b57b54656d743b546efa73764c77866a65934bd96f2678f886813b7 427Module name:com.xxx.xxx 428Version:1.2.2.202 429VersionCode: 1002002202 430PreInstalled:Yes 431Foreground:No --> Indicates that the application is not in the foreground. 432Pid:15440 433Uid:20020029 434Reason:THREAD BLOCK 6S 435appfreeze: com.xxx.xxx THREAD_BLOCK 6S at 20240410164052 436DisplayPowerInfo:powerState: AWAKE 437>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 438``` 439 440#### Obtain the fault occurrence time 441 442Fault report time 443 444``` 445>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 446DOMAIN:AAFWK 447STRINGID: THREAD BLOCK 6S 448TIMESTAMP: 2024/04/10-16:40:52:743 --> The timestamp when the fault is reported. 449PID:15440 450UID:20020029 451PACKAGE NAME:com.xxx.xxx 452PROCESS NAME:com.xxx.xxx 453**************************************** 454``` 455 456Detection durations for different faults in different scenarios 457 458| THREAD_BLOCK_6S |APP_INPUT_BLOCK|LIFECYCLE_TIMEOUT| 459| -------- |--------|--------| 460|Foreground application: 6s<br> Background application: 3s * 5 + 6s = 21s| 5s | Load: 10s<br> Active: 5s<br> Inactive: 0.5s<br> Terminate: 10s<br> Connect: 3s<br> Disconnect: 0.5s<br> Restart: 5s<br> Foreground: 5s<br> Background: 3s| 461 462**NOTE** 4631. The detection duration of **THREAD_BLOCK_3S** or **LIFECYCLE_HALF_TIMEOUT** is half of that of **THREAD_BLOCK_6S** or **LIFECYCLE_TIMEOUT**. **THREAD_BLOCK_3S** and **LIFECYCLE_HALF_TIMEOUT** are warnings and do not report logs independently. **THREAD_BLOCK_6S** and **LIFECYCLE_TIMEOUT** are errors and report logs with the corresponding warning. 4642. If **THREAD_BLOCK_3S** occurs in the foreground application, **THREAD_BLOCK_6S** will be triggered. 4653. The value of **backgroundReportCount_** is **0**. When **THREAD_BLOCK_3S** occurs for five consecutive times (the count is not cleared), the **THREAD_BLOCK_6S** event is reported. Consequently, the detection durations of **THREAD_BLOCK_3S** and **THREAD_BLOCK_6S** are 18s and 21s respectively. 466 467The fault occurrence time can be obtained based on the detection duration and the fault reporting time. 468 469### Viewing **eventHandler** Information 470 471Obtain the fault reporting time, fault cause, ID of the running thread, and start time of the running task of the thread. 472 473``` 474MSG = 475Fault time:2024/02/01-10:04:57 --> Fault reporting time. 476ability:MainAbility foreground timeout --> Fault cause. 477server: 478312522; AbilityRecord::ForegroundAbility; the ForegroundAbility lifecycle starts. 479client: 480312522; AbilityThread::ScheduleAbilityTransaction; the foreground lifecycle. 481mainHandler dump is: 482EventHandler dump begin curTime: 2024-02-01 10:04:57.306 483Event runner (Thread name =, Thread ID = 18083) is running --> Information of the running thread. 484Current Running: start at 2024-02-01 10:04:54.798, Event { send thread = 18132, send time = 2024-02-01 10:04:54.778, handle time = 2024-02-01 10:04:54.778, task name = UIAbilityThread:SendResult } --> Information of the task being-executed on the running thread. 485History event queue information: 486No. 0 : Event { send thread = 18083, send time = 2024-02-01 10:04:46.481, handle time = 2024-02-01 10:04:46.981, trigger time = 2024-02-01 10:04:46.982, completeTime time = 2024-02-01 10:04:46.982, task name = } 487No. 1 : Event { send thread = 18132, send time = 2024-02-01 10:04:47.149, handle time = 2024-02-01 10:04:47.149, trigger time = 2024-02-01 10:04:47.149, completeTime time = 2024-02-01 10:04:47.197, task name = MainThread:BackgroundApplication } 488No. 2 : Event { send thread = 18083, send time = 2024-02-01 10:04:44.329, handle time = 2024-02-01 10:04:47.329, trigger time = 2024-02-01 10:04:47.329, completeTime time = 2024-02-01 10:04:47.329, task name = } 489No. 3 : Event { send thread = 18087, send time = 2024-02-01 10:04:48.091, handle time = 2024-02-01 10.04.48.091, trigger time = 2024-02-01 10:04:48.091, completeTime time = 2024-02-01 10:04:48.091, task name = } 490``` 491 492You can find the lifecycle that times out as follows. 493Common tasks in the thread are of low priority by default. The watchdog tasks exist in the **High-priority event queue**, while input events are of higher priority because they need to be responded in time. 494 495``` 496High priority event queue information: 497No.1 : Event { send thread = 15444, send time = 2024-04-10 04:40:31.379, handle time = 2024-04-10 04:40:31.379, id = 1, caller = [watchdog.cpp(Timer:139)] } 498``` 499 500The possible causes are as follows: 501 5021. Currently, high-priority tasks consist only the watchdog tasks. 503 504``` 505Immediate priority event queue information: 506Total size of Immediate events : 0 507High priority event queue information: 508No.1 : Event { send thread = 18087, send time = 2024-02-0110:04:57.041, handle time =2024-02-01 10:04:57.041, id = 1, caller = [watchdog.cpp(Timer:140)] } 509Total size of High events : 1 510Low priority event queueinformation: 511No.1 : Event { send thread = 18132, send time = 2024-02-01 10:04:54.794, handle time = 2024-02-01 10:04:54.794, task name = , caller = [task_runner_adapter_impl.cpp(PostTask:33)] } 512No.2 : Event { send thread = 18083, send time = 2024-02-01 10:04:54.795, handle time = 2024-02-01 10:04:54.795, task name = , caller = [task_runner_adapter_impl. cpp(PostTask:33)] } 513No.3 : Event { send thread = 18132, send time = 2024-02-01 10:04:54.801, handle time = 2024-02-01 10:04:54.801, task name = UIAbilityThread:AbilityTransaction,caller = [ui_ability_thread.cppScheduleAbilityTransaction: 366)] } 514No.4 : Event { send thread = 18084, send time = 2024-02-01 10:04:54.801, handle time = 2024-02-01 10:04:54.801, task name = , caller = [task_runner_adapter_impl.cpp(PostTask:33)] } 515No.5 : Event { send thread = 18083, send time = 2024-02-01 10:04:54.742, handle time = 2024-02-01 10:04:55.242, task name = , caller = [task_runner_adapter_impl. cpp(PostDelayedTask:43)] } 516No.6 : Event { send thread = 18084, send time = 2024-02-01 10:04:57.015, handle time = 2024-02-01 10:04:57.015, task name = , caller = [task_runner_adapter imp1.cpp(PostTask:33)] } 517No.7 : Event { send thread = 18132, Send time = 2024-02-01 10:04:57.016, handle time = 2024 02-01 10:04:57.016, task name = , caller = [task_runner adapter_impl.cpp(PostTask:33)] } 518No.8 : Event { send thread = 18088, send time = 2024-02-01 10:04:57.018, handle time = 2024-02-01 10:04:57.018, task name = , caller = [taskrunner_adapter_impl.cpp(PostTask:33)] } 519No.9 : Event { send thread = 18088, send time = 2024-02-01 10:04:57.018, handle time = 2024-02-01 10:04:57.018, task name = , caller = [task_runner_adapter_impl.cpp(PostTask: 33)] } 520No.10: Event { send thread = 18083, send time = 2024-02-01 10:04:45.037, handle time = 2024-02-01 10:06:44.464, task name = uv timer task, caller= [ohos loop handler.cpp(OnTriggered:68)] } 521Total size of Low events : 10 522``` 523 524The running task takes a long time and the next watchdog task cannot be executed. 525 5262. There are too many high-priority tasks, and the watchdog tasks are at the bottom of the queue. 527 528``` 529High priority event queue information: 530No.1 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.690, handle time = 2024-03-14 02:40:53.690, task name = , caller = [input_manager_imp1.cpp(OnPointerEvent:465)] } 531No.2 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.699, handle time = 2024-03-14 02:40:53.699, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 532No.3 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.708, handle time = 2024-03-14 02:40:53.708, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 533No.4 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.717, handle time = 2024-03-14 02:40:53.717, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 534No.5 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.726, handle time = 2024-03-14 02:40:53.726, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 535No.6 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.736, handle time = 2024-03-14 02:40:53.736, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 536No.7 : Event { send threac = 3370, send time = 2024-03-14 02:40:53.745, handle time = 2024-03-14 02:40:53.745, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 537No,8 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.754, handle time = 2024-03-14 02:40:53.754, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 538... 539No.190 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.166, handle time = 2024-03-14 02:40:56.166, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 540No.191 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.176, handle time = 2024-03-14 02:40:56.176, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 541No.192 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.186, handle time = 2024-03-14 02:40:56.186, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 542No.193 : Event { send thread = 2923, send time = 2024-03-14 02:40:56.196, handle time = 2024-03-14 02:40:56.196, id= 1, caller = [watchdog.cpp(Timer:140)] } 543No.194 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.196, handle time = 2024-03-14 02:40:56.196, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 544No.195 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.206, handle time = 2024-03-14 02:40:56.206, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 545No.196 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.216, handle time = 2024-03-14 02:40:56.216, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 546No.197 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.226, handle time = 2024-03-14 02:40:56.226, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 547No.198 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.236, handle time = 2024-03-14 02:40:56.236, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 548No.199 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.245, handle time = 2024-03-14 02:40:56.245, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 549No.200 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.254, handle time = 2024-03-14 02:40:56.254, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 550No.201 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.265, handle time = 2024-03-14 02:40:56.265, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 551No.202 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.275, handle time = 2024-03-14 02:40:56.274, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 552No.203 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.284, handle time = 2024-03-14 02:40:56.284, task name = , caller = [input_manager_imp1.cpp(OnPointerEvent:465)] } 553No.204 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.294, handle time = 2024-03-14 02:40:56.294, task name = , caller = [input manager_impl.cpp(OnPointerEvent:465)] } 554No.205 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.305, handle time = 2024-03-14 02:40:56.305, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 555``` 556 557### Viewing Stack Information 558 559Check the stack using the obtained PID and TID. The result may show as follows: 560 5611. The stack information is clearly displayed. 562 563``` 564Tid:3025, Name: xxx 565# 00 pc 00000000001b4094 /system/lib/ld-musl-aarch64.so.1(__timedwait_cp+188)(b168f10a179cf6050a309242262e6a17) 566# 01 pc 00000000001b9fc8 /system/lib/ld-musl-aarch64.so.1(__pthread_mutex_timedlock_inner+592)(b168f10a179cf6050a309242262e6a17) 567# 02 pc 00000000000c3e40 /system/lib64/libc++.so(std::__h::mutex::lock()+8)(9cbc937082b3d7412696099dd58f4f78242f9512) --> The so. file is suspended while waiting for a lock. 568# 03 pc 000000000007ac4c /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteConnectionPool::Container::Release(std::__h::shared_ptr<OHOS::NativeRdb::SqliteConnectionPool::ConnNode>)+60)(5e8443def4695e8c791e5f847035ad9f) 569# 04 pc 000000000007aaf4 /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteConnectionPool::ReleaseNode(std::__h::shared_ptr<OHOS::NativeRdb::SqliteConnectionPool::ConnNode>)+276)(5e8443def4695e8c791e5f847035ad9f) 570# 05 pc 000000000007a8c0 /system/lib64/platformsdk/libnative_rdb.z.so(5e8443def4695e8c791e5f847035ad9f) 571# 06 pc 00000000000b36ec /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteSharedResultSet::Close()+324)(5e8443def4695e8c791e5f847035ad9f) 572# 07 pc 000000000006da94 /system/lib64/module/data/librelationalstore.z.so(OHOS::RelationalStoreJsKit::ResultSetProxy::Close(napi_env__*, napi_callback_info__*) (.cfi)+212)(5c7c67512e12e0e53fd23e82ee576a88) 573# 08 pc 0000000000034408 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+220)(f271f536a588ef9d0dc5328c70fce511) 574# 09 pc 00000000002d71d0 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40) 575# 10 at parseResultSet (entry/build/default/cache/default/default@CompileArkTS/esmodule/release/datamanager/datawrapper/src/main/ets/database/RdbManager.ts:266:1) 576# 11 at query (entry/build/default/cache/default/default@CompileArkTS/esmodule/release/datamanager/datawrapper/src/main/ets/database/RdbManager.ts:188:1) 577``` 578 579The so. file is suspended while waiting for a lock. In this case, locate the error code by decompiling and check the context to fix the bug. 580 5812. The IPC request is suspended. 582 583``` 584Tid:53616, Name:xxx 585# 00 pc 0000000000171c1c /system/lib/ld-musl-aarch64.so.1(ioctl+176)(b168f10a179cf6050a309242262e6a17) 586# 01 pc 0000000000006508 /system/lib64/chipset-pub-sdk/libipc_common.z.so(OHOS::BinderConnector::WriteBinder(unsigned long, void*)+100)(1edec25445c569dd1093635c1da3bc0a) --> The binder is suspended. 587# 02 pc 000000000004d500 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::TransactWithDriver(bool)+296)(6151eca3b47aa2ab3e378e6e558b90f3) 588# 03 pc 000000000004c6c0 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::WaitForCompletion(OHOS::MessageParcel*, int*)+128)(6151eca3b47aa2ab3e378e6e558b90f3) 589# 04 pc 000000000004c304 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::SendRequest(int, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+348)(6151eca3b47aa2ab3e378e6e558b90f3) 590# 05 pc 00000000000319ac /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequestInner(bool, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+124)(6151eca3b47aa2ab3e378e6e558b90f3) 591# 06 pc 0000000000031cfc /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequest(unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+184)(6151eca3b47aa2ab3e378e6e558b90f3) 592# 07 pc 0000000000023c7c /system/lib64/libipc.dylib.so(<ipc::remote::obj::RemoteObj>::send_request+268)(7006cb5520edc22f64d04df86cb90152) 593# 08 pc 000000000000b904 /system/lib64/libasset_sdk.dylib.so(<asset_sdk::Manager>::send_request+48)(4073ec22b58b83f79883d5fc8102ce77) 594# 09 pc 000000000000b600 /system/lib64/libasset_sdk.dylib.so(<asset_sdk::Manager>::query+156)(4073ec22b58b83f79883d5fc8102ce77) 595# 10 pc 0000000000006d94 /system/lib64/libasset_sdk_ffi.z.so(query_asset+116)(9a309896092ba014c878289a54688679) 596# 11 pc 0000000000006740 /system/lib64/module/security/libasset_napi.z.so((anonymous namespace)::NapiQuerySync(napi_env__*, napi_callback_info__*) (.cfi)+220)(ef7afe850712e4822f085ed0ac184e8a) 597# 12 pc 0000000000034408 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+220)(f271f536a588ef9d0dc5328c70fce511) 598``` 599 6003. The warning and error stacks are the same. The stack top displays the synchronous codes. 601 602The warning and error stacks are as follows: 603 604``` 605Tid:14727, Name:xxx 606# 00 pc 00000000001c4c60 /system/lib/ld-musl-aarch64.so.1(pread+72)(b168f10a179cf6050a309242262e6a17) 607# 01 pc 0000000000049154 /system/lib64/platformsdk/libsqlite.z.so(unixRead+180)(48485aa23da681fc87d8dc0b4be3e34c) 608# 02 pc 0000000000053e98 /system/lib64/platformsdk/libsqlite.z.so(readDbPage+116)(48485aa23da681fc87d8dc0b4be3e34c) 609# 03 pc 0000000000053d48 /system/lib64/platformsdk/libsqlite.z.so(getPageNormal+864)(48485aa23da681fc87d8dc0b4be3e34c) 610# 04 pc 00000000000757a0 /system/lib64/platformsdk/libsqlite.z.so(getAndInitPage+216)(48485aa23da681fc87d8dc0b4be3e34c) 611# 05 pc 0000000000077658 /system/lib64/platformsdk/libsqlite.z.so(moveToLeftmost+164)(48485aa23da681fc87d8dc0b4be3e34c) 612# 06 pc 000000000006aa34 /system/lib64/platformsdk/libsqlite.z.so(sqlite3VdbeExec+34532)(48485aa23da681fc87d8dc0b4be3e34c) 613# 07 pc 000000000002e424 /system/lib64/platformsdk/libsqlite.z.so(sqlite3_step+644)(48485aa23da681fc87d8dc0b4be3e34c) 614# 08 pc 00000000000b1a70 /system/lib64/platformsdk/libnative_rdb.z.so(FillSharedBlockOpt+408)(5e8443def4695e8c791e5f847035ad9f) 615# 09 pc 0000000000082a94 /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteStatement::FillBlockInfo(OHOS::NativeRdb::SharedBlockInfo*) const+76)(5e8443def4695e8c791e5f847035ad9f) 616# 10 pc 00000000000b4214 /system/lib64/platformsdk/libnative_rdb.z.so(OHOS::NativeRdb::SqliteSharedResultSet::ExecuteForSharedBlock(OHOS::AppDataFwk::SharedBlock*, int, int, bool)+236)(5e8443def4695e8c791e5f847035ad9f) 617``` 618 619Based on the trace information, check whether the called function of stack top times out. 620 6214. The stack is a temporary stack, and the warning stack is not the same as the error stack. 622 623Warning stack: 624 625``` 626Tid:3108, Name:xxx 627# 00 pc 0000000000146e2c /system/lib/ld-musl-aarch64.so.1(open64+224)(b168f10a179cf6050a309242262e6a17) 628# 01 pc 0000000000014600 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::ZipFileReader::init()+600)(c4893935af8fc8cb36569be5ccdebfa9) 629# 02 pc 0000000000014144 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::ZipFileReader::CreateZipFileReader(std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+392)(c4893935af8fc8cb36569be5ccdebfa9) 630# 03 pc 000000000000f724 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::ZipFile::Open()+728)(c4893935af8fc8cb36569be5ccdebfa9) 631# 04 pc 000000000000a808 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::Extractor::Init()+124)(c4893935af8fc8cb36569be5ccdebfa9) 632# 05 pc 000000000000c4a4 /system/lib64/chipset-pub-sdk/libextractortool.z.so(OHOS::AbilityBase::ExtractorUtil::GetExtractor(std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&, bool&, bool)+596)(c4893935af8fc8cb36569be5ccdebfa9) 633# 06 pc 00000000000391e4 /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::GetIndexData(char const*, std::__h::unique_ptr<unsigned char [], std::__h::default_delete<unsigned char []>>&, unsigned long&)+284)(5c4263e737507b4a8f2ee7196a152dbd) 634# 07 pc 0000000000038590 /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::HapResource::LoadFromHap(char const*, std::__h::shared_ptr<OHOS::Global::Resource::ResConfigImpl>&, bool, bool, unsigned int const&)+80)(5c4263e737507b4a8f2ee7196a152dbd) 635# 08 pc 00000000000384e8 /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::HapResource::Load(char const*, std::__h::shared_ptr<OHOS::Global::Resource::ResConfigImpl>&, bool, bool, unsigned int const&)+364)(5c4263e737507b4a8f2ee7196a152dbd) 636# 09 pc 000000000002f118 /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::HapManager::AddResourcePath(char const*, unsigned int const&)+280)(5c4263e737507b4a8f2ee7196a152dbd) 637# 10 pc 000000000002efdc /system/lib64/platformsdk/libglobal_resmgr.z.so(OHOS::Global::Resource::HapManager::AddResource(char const*, unsigned int const&)+52)(5c4263e737507b4a8f2ee7196a152dbd) 638``` 639 640Error stack: 641 642``` 643Tid:3108, xxx 644# 00 pc 00000000003e13cc /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::JSObject::GetProperty(panda::ecmascript::JSThread*, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue> const&, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue> const&, panda::ecmascript::JSShared::SCheckMode)+164)(13376099388381a01b166c00a8af99fb) 645# 01 pc 00000000003d5518 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::JSIterator::IteratorStep(panda::ecmascript::JSThread*, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue> const&)+228)(13376099388381a01b166c00a8af99fb) 646# 02 pc 0000000000570fa8 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::RuntimeStubs::StArraySpread(unsigned long, unsigned int, unsigned long)+592)(13376099388381a01b166c00a8af99fb) 647# 03 pc 00000000002d53c0 /system/lib64/module/arkcompiler/stub.an(RTStub_CallRuntime+40) 648# 04 at doTask (product/phone/build/default/cache/default/default@CompileArkTS/esmodule/release/staticcommon/launchercommon/src/main/ets/db/RdbTaskPool.ts:1:1) 649# 05 at update (product/phone/build/default/cache/default/default@CompileArkTS/esmodule/release/staticcommon/launchercommon/src/main/ets/db/RdbTaskPool.ts:1:1) 650# 06 at updateAppNameByAbilityInfoAndType (product/phone/build/default/cache/default/default@CompileArkTS/esmodule/release/staticcommon/launchercommon/src/main/ets/db/RdbStoreManager.ts:12:1) 651# 07 at anonymous (product/phone/build/default/cache/default/default@CompileArkTS/esmodule/release/staticcommon/launchercommon/src/main/ets/model/AppModel.ts:0:1) 652# 08 pc 0000000000304a94 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::InterpreterAssembly::Execute(panda::ecmascript::EcmaRuntimeCallInfo*)+144)(13376099388381a01b166c00a8af99fb) 653# 09 pc 0000000000201d84 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::builtins::BuiltinsPromiseJob::PromiseReactionJob(panda::ecmascript::EcmaRuntimeCallInfo*)+348)(13376099388381a01b166c00a8af99fb) 654# 10 pc 00000000002d6e14 /system/lib64/module/arkcompiler/stub.an(RTStub_AsmInterpreterEntry+208) 655``` 656 657In this case, the stacks are irregular because they are captured during thread running, which indicates that the thread is not suspended. If the thread is busy, analyze and optimize the application based on the trace and hilog logs. 658 659### Viewing Binder Information 660 661Obtain the Binder information after the warning event if it occurs, otherwise, obtain the Binder information after the block event. 662 6631. Obtain the Binder information. 664 665``` 666PeerBinderCatcher -- pid==35854 layer_ == 1 667BinderCatcher -- 668 35854:35854 to 52462:52462 code 3 wait:27.185154163 s frz_state:3 -> 35854:35854 to 52462:53462 code 3 wait:27.185154163 s 669 ... 670 52462:52462 to 1386:0 code 13 wait:24.733640622 s frz_state:3 -> 52462:52462 to 1386:0 code 13 wait:24.733640622 s 671``` 672This example shows that there is a call chain from the main thread of process 35854 to process 52462 and to process 1386. You can analyze the cause of the block event based on the stack information of the peer processes. 673 6742. Check whether the thread ID is **0**. 675 676When the thread ID of a peocess is **0**, it indicates that the application is IPC_FULL. That is, all IPC threads of the application are in use, and no other thread is allocated to the request. As a result, the request is blocked. For example, the thread ID of 1386 process is **0**, which can be analyzed based on its stack. 677 678``` 679pid context request started max ready free_async_space 680 68135862 binder 0 2 16 2 519984 682 68335854 binder 0 2 16 3 520192 684 68535850 binder 0 2 16 3 520192 686 68713669 binder 0 1 16 3 520192 688 689... 690 6911386 binder 1 15 16 0 517264 -> binderInfo 692 6931474 binder 0 2 16 4 520192 694``` 695 696As shown in the stack, the number of threads in the ready state of process 1386 is 0. This indicates that some IPC threads of the process may be blocked. To analyze why the IPC threads are not released, you can check the following causes: An IPC thread that holds the lock is blocked. As a result, other threads are suspended while waiting for the lock. 697 698**free_async_space** is unavailable. As a result, there is no sufficient buffer space for the request of the new IPC thread. It should be noted that this value is required by both synchronous and asynchronous requests. Generally, **free_async_space** is unavailable when a large number of asynchronous requests are sent in a short period of time. 699 7003. Check whether the value of **waitTime** is too small. 701 702**waitTime** indicates the IPC duration. If the value of **waitTime** is far less than the fault detection duration, the suspension is not caused by the IPC request. 703If the main thread on the application sends multiple IPC requests in a short period of time, the value of **waitTime** will be large. As a result, the thread is suspended. 704 705In this case, you can check the following items: 706 - Whether the wait time of a single request is as expected. If the wait time of a single request is greater than the normal value (for example, the request whose normal wait time is 20 ms waits for 1s), check why the API performance does not meet the expectation. 707 - Whether the frequent calling on the application is proper. 708 7094. Check whether there is no calling relationship and whether the stack is an IPC stack. 710 711Check whether the stack is a temporary stack, that is, whether the warning stack is the same as the error stack. It is possible that the warning stack is an IPC stack, and the block stack is a temporary stack because the IPC request has ended when the binder is captured, and the IPC request takes a short time. 712It should be noted that binder information is not obtained in real time when a fault occurs and is delayed. For faults that require half-period detection, binder information is accurately captured because most binder information can be collected within the fault period. For other faults, the off-site binder information may be captured when the reporting is delayed. 713 714You can view the execution duration of the binder based on the trace. 715 716### Analyzing Hilog logs 717 718#### DFX-related Logs 719 7201. Fault report (reportEvent): 721 722 723 7242. Stack capture (signal: 35): 725 726 727 7283. Background application check for five times before reporting, about 21s: 729 730 731 7324. Exit reason record: 733 734 735 7365. APP_FREEZE kills the application: 737 738 739 740#### Procedure 741 742View [Obtain the fault occurrence time](#obtain-the-fault-occurrence-time), and determine the fault occurrence time based on the fault type. Analyze the hilog log in the specific period to obtain the status of the running thread. 743 744- If no application log is printed, the application is frozen when the logging API is invoked. 745 746  747 748 **...** 749 750  751 752 As shown in the preceding figure, the **APP_INPUT_BLOCK** error is reported at **07:24:08.167**, and the application main thread does not print logs after **07:24:01.581**. Check whether the logic of **FormManagerService: ** 753 754 **[form_mgr_proxy.cpp(GetFormsInfoByApp:1128)]** times out. 755 756- If the application logs are printed frequently, check whether the logs are normal. 757 758  759 760 As shown in the preceding figure, a large number of logs are printed before the process is killed by **APP_FREEZE**. Check whether the logs are normal in the **ImageEffect** domain. 761 762### Analyzing Trace Logs 763 764The possible causes are as follows: 765 7661. The duration of each service is not long, but the number of services is too large.Therefore, the process runs intensively in a long period of time and occupies the main thread. 767 768 769 770 771 772In the preceding figure, the **ohos.animator** in **PriviewArea::updateShotComponent** is executed for 9.2s. 773 774The thread is busy executing a service cyclically and analyzing each service segment. 775 776- If the service scenario is not normal (the service should not be called frequently), analyze the service code and find out why the service is executed cyclically. 777 778- Otherwise, check whether the service segment takes more time than expected and why the performance does not meet the design specifications. 779 7802. The process times out when executes a function. 781 782 783 784In the preceding figure, the execution duration of **OHOS::AppExecFwk::FormMgrAdapter::GetFormsInfoByApp** exceeds 8s. 785 786## Case Study 787 788### Typical Case of ThreadBlock - Incorrect Use of Locks 789 790#### Background 791 792The xxx service reports the appfreeze crash **THREAD_BLOCK_6S**. 793 794#### Error Codes 795 796The fourth line is locked, while the function in the sixth line fails and returns without unlocking. As a result, other threads are waiting for the locked function. 797 798```cpp 799int xxx() 800{ 801 ... 802 mutex_.lock(); 803 AIContext aiContext; 804 if (ConvertRpcHandle2AIContext(inputs[0], aiContext) != aicp::SUCCESS) { 805 return FAILED; 806 } 807 ... 808} 809``` 810 811#### Impact 812 813The background application is suspended and related functions are unavailable, but it is imperceptible to the user. 814 815#### Fault Locating 816 817Extract the key fault logs. 818 819``` 820appfreeze: com.huawei.hmsapp.xxx THREAD_BLOCK_6S at 20240408082432 821DisplayPowerInfo:powerState:AWAKE 822``` 823 824The value of **Foreground** indicates that **hiai** is a background application. Therefore, it can be inferred that when the 3s event is reported, the background application is suspended for **18s**. 825 826``` 827Module name:com.xxx.xxx.xxx 828Version:1.2.2.202 829VersionCode:1002002202 830PreInstalled:Yes 831Foreground: No --> Indicates that the application is in the background. 832Pid:43675 833Uid:20020029 834Reason:THREAD_BLOCK_6S 835``` 836 837The **THREAD_BLOCK_3S** event is reported at **08:24:29:612**. 838The **THREAD_BLOCK_6S** event is reported at **08:24:32:638**. The interval is 3s as expected. 839 840``` 841>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 842DOMAIN:AAFWK 843STRINGID:THREAD_BLOCK_6S 844TIMESTAMP:2024/04/08-08:24:32:638 845PID:43675 846UID:20020029 847PACKAGE_NAME:com.xxx.xxx.xxx 848PROCESS_NAME:com.xxx.xxx.xxx 849******************************************* 850start time: 2024/04/08-08:24:29:627 851DOMAIN = AAFWK 852EVENTNAME = THREAD_BLOCK_3S 853TIMESTAMP = 2024/04/08-08:24:29:612 854PID = 43675 855UID = 20020029 856PACKAGE_NAME = com.xxx.xxx.xxx 857PROCESS_NAME = com.xxx.xxx.xxx 858``` 859 860When the **THREAD_BLOCK_3S** event is reported, the **EventHandler** is captured at **08:24:29.413**. The cause is as expected: "App main thread is not response!" The main thread does not respond. The running task is send at **08:24:01.514**. 861 862``` 863MSG = 864Fault time:2024/04/08-08:24:29 865App main thread is not response! 866mainHandler dump is: 867 EventHandler dump begin curTime: 2024-04-08 08:24:29.413 868 Event runner (Thread name = , Thread ID = 43675) is running 869 Current Running: start at 2024-04-08 08:24:01.514, Event { send thread = 43675, send time = 2024-04-08 08:24:01.514, handle time = 2024-04-08 08:24:01.514, task name = uvLoopTask } 870``` 871 872The watchdog task is in the high priority event queue. As shown in the following figure, a task is thrown to the main thread every 3 seconds, which is as expected. 873 874The queue of **THREAD_BLOCK_3S** is similar to that of **THREAD_BLOCK_6S**, with one more event in the queue of **THREAD_BLOCK_6S**. 875 876The earliest event is send at **08:24:11.388**, which is 18s earlier than the report time **08:24:29:612** as expected. 877 878``` 879 High priority event queue information: 880 No.1 : Event { send thread = 43679, send time = 2024-04-08 08:24:11.388, handle time = 2024-04-08 08:24:11.388, id = 1, caller = [watchdog.cpp(Timer:139)] } 881 No.2 : Event { send thread = 43679, send time = 2024-04-08 08:24:14.458, handle time = 2024-04-08 08:24:14.458, id = 1, caller = [watchdog.cpp(Timer:139)] } 882 No.3 : Event { send thread = 43679, send time = 2024-04-08 08:24:17.383, handle time = 2024-04-08 08:24:17.383, id = 1, caller = [watchdog.cpp(Timer:139)] } 883 No.4 : Event { send thread = 43679, send time = 2024-04-08 08:24:20.363, handle time = 2024-04-08 08:24:20.363, id = 1, caller = [watchdog.cpp(Timer:139)] } 884 No.5 : Event { send thread = 43679, send time = 2024-04-08 08:24:23.418, handle time = 2024-04-08 08:24:23.418, id = 1, caller = [watchdog.cpp(Timer:139)] } 885 No.6 : Event { send thread = 43679, send time = 2024-04-08 08:24:26.369, handle time = 2024-04-08 08:24:26.369, id = 1, caller = [watchdog.cpp(Timer:139)] } 886 No.7 : Event { send thread = 43679, send time = 2024-04-08 08:24:29.412, handle time = 2024-04-08 08:24:29.412, id = 1, caller = [watchdog.cpp(Timer:139)] } 887``` 888 889To sum up, the main thread of the application starts to run this task at **08:24:01.514**. The first **THREAD_BLOCK_3S** event occurs at **08:24:11.388**, and the application is suspended at about **08:24:11**. 890 891View the main thread stack at **xxx_request_client.so -> libsamgr_proxy.z.so -> libipc_core.z.so(OHOS::BinderConnector::WriteBinder)**. 892 893The main thread initiates an IPC request, but the peer process does not response. As a result, the process is suspended, as shown in the following stack. 894 895``` 896Tid:43675, Name:xxx 897# 00 pc 0000000000168c44 /system/lib/ld-musl-aarch64.so.1(ioctl+176)(91b804d2409a13f27463debe9e19fb5d) 898# 01 pc 0000000000049268 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderConnector::WriteBinder(unsigned long, void*)+112)(e59500a4ea66775388332f6e3cc12fe3) 899# 02 pc 0000000000054fd4 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::TransactWithDriver(bool)+296)(e59500a4ea66775388332f6e3cc12fe3) 900# 03 pc 00000000000544c8 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::WaitForCompletion(OHOS::MessageParcel*, int*)+304)(e59500a4ea66775388332f6e3cc12fe3) 901# 04 pc 0000000000053c84 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::SendRequest(int, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+312)(e59500a4ea66775388332f6e3cc12fe3) 902# 05 pc 000000000002d6d8 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequestInner(bool, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+128)(e59500a4ea66775388332f6e3cc12fe3) 903# 06 pc 0000000000030e00 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::GetProtoInfo()+396)(e59500a4ea66775388332f6e3cc12fe3) 904# 07 pc 000000000002e990 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::WaitForInit()+292)(e59500a4ea66775388332f6e3cc12fe3) 905# 08 pc 0000000000036cd0 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCProcessSkeleton::FindOrNewObject(int)+116)(e59500a4ea66775388332f6e3cc12fe3) 906# 09 pc 00000000000571cc /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::UnflattenObject(OHOS::Parcel&)+272)(e59500a4ea66775388332f6e3cc12fe3) 907# 10 pc 00000000000463a4 /system/lib64/platformsdk/libipc_core.z.so(OHOS::MessageParcel::ReadRemoteObject()+116)(e59500a4ea66775388332f6e3cc12fe3) 908# 11 pc 000000000001250c /system/lib64/chipset-pub-sdk/libsamgr_proxy.z.so(OHOS::SystemAbilityManagerProxy::CheckSystemAbility(int, bool&)+952)(6f113f37ac6ac882cfa16077ad5b406a) 909# 12 pc 0000000000010e7c /system/lib64/chipset-pub-sdk/libsamgr_proxy.z.so(OHOS::SystemAbilityManagerProxy::GetSystemAbilityWrapper(int, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+232)(6f113f37ac6ac882cfa16077ad5b406a) 910# 13 pc 00000000000118b8 /system/lib64/chipset-pub-sdk/libsamgr_proxy.z.so(OHOS::SystemAbilityManagerProxy::Recompute(int, int)+132)(6f113f37ac6ac882cfa16077ad5b406a) 911# 14 pc 0000000000011170 /system/lib64/chipset-pub-sdk/libsamgr_proxy.z.so(OHOS::DynamicCache<int, OHOS::sptr<OHOS::IRemoteObject>>::QueryResult(int, int)+316)(6f113f37ac6ac882cfa16077ad5b406a) 912# 15 pc 0000000000007e0c xxx_request_client.so(xxx::RPCRequestClient::GetService()+540)(557450139184527807025a632613fd76) 913# 16 pc 0000000000008824 xxx_request_client.so(xxx::RPCRequestClient::Init()+16)(557450139184527807025a632613fd76) 914# 17 pc 0000000000008d60 xxx_request_client.so(CreateRpcRequestByServiceName+104)(557450139184527807025a632613fd76) 915# 18 pc 0000000000008f98 xxx_request_client.so(CreateRpcRequest+72)(557450139184527807025a632613fd76) 916# 19 pc 0000000000002944 xxx_rpc_client.so(xxx::xxx::RpcRequestClient::RpcRequestClient()+224)(02343ed2fff69759d408b23eaf69fcde) 917``` 918 919Check the binderCatcher. The main thread **43675** is communicating with process **979** and the **BinderCatcher** is suspended for 27s. 920 921``` 922PeerBinderCatcher -- pid==43675 layer_ == 1 923BinderCatcher -- 924 43675:43675 to 979:0 code 5f475249 wait:27.104545829 s frz_state:1 --> The binder communication waits for 27s. 925 57187:39147 to 28644:30753 code 0 wait:0.337894271 s frz_state:3 926 57187:39151 to 28644:28652 code 7 wait:0.531140625 s frz_state:3 927 57187:39150 to 28644:31297 code 0 wait:0.976419270 s frz_state:3 928 57187:38979 to 28644:32554 code 0 wait:0.22108334 s frz_state:3 929 57187:39149 to 28644:30754 code 0 wait:0.534261979 s frz_state:3 930 57187:38949 to 28644:31301 code 0 wait:0.977779166 s frz_state:3 931 57187:39172 to 28644:35667 code 0 wait:1.47387500 s frz_state:3 932 57187:39173 to 28644:28822 code 0 wait:0.565389063 s frz_state:3 933 1477:1676 to 1408:2026 code 17 wait:0.0 s frz_state:3 934 628:8136 to 979:0 code 2 wait:13166.722870859 s frz_state:1 935``` 936 937Check the main thread stack of process **979**, and it shows that **xxxserver** is waiting for lock release. This fault is caused by improper use of locks. 938 939``` 940PeerBinder Stacktrace -- 941PeerBinderCatcher start catcher stacktrace for pid : 979 942Result: 0 ( no error ) 943Timestamp:2024-04-08 08:24:29.000 944Pid:979 945Uid:3094 946Process name:xxxserver 947Process life time:60410s 948Tid:979, Name:xxxserver 949# 00 pc 00000000001aafc4 /system/lib/ld-musl-aarch64.so.1(__timedwait_cp+192)(91b804d2409a13f27463debe9e19fb5d) 950# 01 pc 00000000001b0d50 /system/lib/ld-musl-aarch64.so.1(__pthread_mutex_timedlock_inner+592)(91b804d2409a13f27463debe9e19fb5d) 951# 02 pc 00000000000c38e0 /system/lib64/libc++.so(std::__h::mutex::lock()+8)(0b61ba21a775725a1bd8802a393b133afbc503a5) --> The lock() function is called and the process waits for it. 952# 03 pc 00000000000086dc xxx_server.so(xxx::xxx::InitImpl(int, std::__h::vector<xxx::xxx::RpcHandle, std::__h::allocator<xxx::xxx::RpcHandle>> const&, std::__h::vector<xxx::xxx::RpcHandle, std::__h::allocator<xxx::xxx::RpcHandle>>&)+84)(f4bb275898d797b22eae35fe48db9009) 953# 04 pc 000000000000798c xxx_request_server.so(xxx::RPCRequestStub::SyncExecute(OHOS::MessageParcel&, OHOS::MessageParcel&)+164)(70cbb10c758902c1e3e179efc93ce0af) 954# 05 pc 0000000000008314 xxx_request_server.so(xxx::RPCRequestStub::OnRemoteRequest(unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+300)(70cbb10c758902c1e3e179efc93ce0af) 955# 06 pc 00000000000153e4 /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPCObjectStub::SendRequest(unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+604)(25b3d63905ef47289c096ea42ba2d86a) 956# 07 pc 000000000002b464 /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::OnTransaction(unsigned char const*)+1220)(25b3d63905ef47289c096ea42ba2d86a) 957# 08 pc 000000000002baec /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::HandleCommandsInner(unsigned int)+368)(25b3d63905ef47289c096ea42ba2d86a) 958# 09 pc 000000000002a6b0 /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::HandleCommands(unsigned int)+60)(25b3d63905ef47289c096ea42ba2d86a) 959# 10 pc 000000000002a4dc /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::StartWorkLoop()+120)(25b3d63905ef47289c096ea42ba2d86a) 960# 11 pc 000000000002bc2c /system/lib64/chipset-pub-sdk/libipc_single.z.so(OHOS::IPC_SINGLE::BinderInvoker::JoinThread(bool)+92)(25b3d63905ef47289c096ea42ba2d86a) 961# 12 pc 0000000000004bd4 xxxserver(02cff7e5dce05d6d28096601458b6f6d) 962# 13 pc 00000000000a3b58 /system/lib/ld-musl-aarch64.so.1(libc_start_main_stage2+64)(91b804d2409a13f27463debe9e19fb5d) 963``` 964 965The error code can be located by decompiling, and the use of the lock can be checked based on the context. 966 967#### Solution 968 969```cpp 970int xxx() 971{ 972 ... 973 mutex_.lock(); 974 AIContext aiContext; 975 if (ConvertRpcHandle2AIContext(inputs[0], aiContext) != aicp::SUCCESS) { 976 return FAILED; 977 } 978 ... 979} 980``` 981 982The preceding codes can be modified as follows: 983 984```cpp 985int xxx() 986{ 987 ... 988 AIContext aiContext; 989 if (ConvertRpcHandle2AIContext(inputs[0], aiContext) != aicp::SUCCESS) { 990 return FAILED; 991 } 992 mutex_.lock(); 993 ... 994} 995``` 996 997Adjust the lock properly based on the context. 998 999#### Suggestions 1000 10011. Pay special attention to the time sequence and deadlock during multi-thread interaction. 1002 1003### Typical Case of **APP_INPUT_BLOCK** - Full Component Update 1004 1005#### Background 1006 1007When the theme is switched, the system is suspended, and the appfreeze fault of the sceneboard is reported. 1008 1009This appfreeze fault occurs when the thread is busy. 1010 1011#### Error Codes 1012 1013Component update and reuse are controlled by the **key** value of the component. When a page is updated, if the **key** value of the component remains unchanged, the original component is reused. If the **key** value changes, the component and its subcomponents are updated. 1014 1015This function is used to generate the **key** of the home screen component and is associated with **themeStyle**. When a user continuously switches the theme on the home screen, the component is repeatedly refreshed in full mode. As a result, the system stops responding. 1016 1017```ts 1018private getForeachKey(item: xxx): string { 1019 ... 1020 return `${item.xxx2}${item.xxx2}...${item.themeStyle}`; 1021} 1022``` 1023 1024#### Impact 1025 1026There is a high probability that the screen freezes when the theme is switched on the integrated home screen. When the user clicks, the screen does not respond and then returns to the lock screen, 1027 1028which severely affect user experience. 1029 1030#### Fault Locating 1031 1032Extract the key fault logs. 1033 1034``` 1035appfreeze: com.ohos.sceneboard APP_INPUT_BLOCK at 20240319022527 1036DisplayPowerInfo:powerState:AWAKE 1037``` 1038 1039The **APP_INPUT_BLOCK** event is reported at **14:40:59:440**. 1040 1041``` 1042DOMAIN:AAFWK 1043STRINGID:APP_INPUT_BLOCK 1044TIMESTAMP:2024/03/14-14:40:59:440 --> Fault report time. 1045PID:2918 1046UID:20020017 1047PACKAGE_NAME:com.ohos.sceneboard 1048PROCESS_NAME:com.ohos.sceneboard 1049``` 1050 1051The reported cause: "User input does not respond!" There is no response to the user input event. 1052The running task of the main thread (TID = PID) starts at **14:40:53.499** and is not complete until the **Fault time** **14:40:58**. 1053 1054``` 1055MSG = 1056Fault time:2024/03/14-14:40:58 1057User input does not respond! 1058mainHandler dump is: 1059 EventHandler dump begin curTime: 2024-03-14 02:40:58.520 1060 Event runner (Thread name = , Thread ID = 2918) is running 1061 Current Running: start at 2024-03-14 02:40:53.499, Event { send thread = 2918, send time = 2024-03-14 02:40:53.499, handle time = 2024-03-14 02:40:53.499, task name = } 1062``` 1063 1064User input events need to be responded immediately. Therefore, user input events are in the high priority event queue, together with the watchdog tasks. 1065 1066In the following example, more than 200 input events are blocked in the queue and are not processed. 1067 1068``` 1069 High priority event queue information: 1070 No.1 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.690, handle time = 2024-03-14 02:40:53.690, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1071 No.2 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.699, handle time = 2024-03-14 02:40:53.699, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1072 No.3 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.708, handle time = 2024-03-14 02:40:53.708, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1073 No.4 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.717, handle time = 2024-03-14 02:40:53.717, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1074 No.5 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.726, handle time = 2024-03-14 02:40:53.726, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1075 No.6 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.736, handle time = 2024-03-14 02:40:53.736, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1076 No.7 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.745, handle time = 2024-03-14 02:40:53.745, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1077 No.8 : Event { send thread = 3370, send time = 2024-03-14 02:40:53.754, handle time = 2024-03-14 02:40:53.754, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1078 ... 1079 No.190 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.166, handle time = 2024-03-14 02:40:56.166, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1080 No.191 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.176, handle time = 2024-03-14 02:40:56.176, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1081 No.192 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.186, handle time = 2024-03-14 02:40:56.186, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1082 No.193 : Event { send thread = 2923, send time = 2024-03-14 02:40:56.196, handle time = 2024-03-14 02:40:56.196, id = 1, caller = [watchdog.cpp(Timer:140)] } 1083 No.194 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.196, handle time = 2024-03-14 02:40:56.196, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1084 No.195 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.206, handle time = 2024-03-14 02:40:56.206, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1085 No.196 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.216, handle time = 2024-03-14 02:40:56.216, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1086 No.197 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.226, handle time = 2024-03-14 02:40:56.226, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1087 No.198 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.236, handle time = 2024-03-14 02:40:56.236, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1088 No.199 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.245, handle time = 2024-03-14 02:40:56.245, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1089 No.200 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.254, handle time = 2024-03-14 02:40:56.254, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1090 No.201 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.265, handle time = 2024-03-14 02:40:56.265, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1091 No.202 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.275, handle time = 2024-03-14 02:40:56.274, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1092 No.203 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.284, handle time = 2024-03-14 02:40:56.284, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1093 No.204 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.294, handle time = 2024-03-14 02:40:56.294, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1094 No.205 : Event { send thread = 3370, send time = 2024-03-14 02:40:56.305, handle time = 2024-03-14 02:40:56.305, task name = , caller = [input_manager_impl.cpp(OnPointerEvent:465)] } 1095``` 1096 1097The input event triggers the main thread task of the application. However, the execution is not complete within 6 seconds and no response is returned. As a result, the ANR times out. 1098In this case, you only need to find out the task that the input triggers and why the task execution times out. 1099 1100In the running main thread stack, the **ark_jsruntime GetCurrentThreadId** function at the stack top is not lock blocking or time-consuming. The captured stack is a transient stack that is useless for analysis. 1101 1102``` 1103Tid:2918, Name:ohos.sceneboard 1104# 00 pc 000000000009f73c /system/lib/ld-musl-aarch64.so.1(8fa55898166cd804dad43d909b5319cc) 1105# 01 pc 000000000054b7b4 /system/lib64/platformsdk/libark_jsruntime.so(panda::os::thread::GetCurrentThreadId()+12)(7715646e48f750f3dc31e660b056eb43) 1106# 02 pc 00000000002107a4 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::EcmaVM::CheckThread() const+200)(7715646e48f750f3dc31e660b056eb43) 1107# 03 pc 0000000000432998 /system/lib64/platformsdk/libark_jsruntime.so(panda::JSNApi::GetHandleAddr(panda::ecmascript::EcmaVM const*, unsigned long)+64)(7715646e48f750f3dc31e660b056eb43) 1108# 04 pc 000000000003eeb8 /system/lib64/platformsdk/libace_napi.z.so(ArkNativeReference::Get()+32)(c3a760aff0c73a2e76accaf518321fc9) 1109# 05 pc 0000000000043cb4 /system/lib64/platformsdk/libace_napi.z.so(napi_get_reference_value+48)(c3a760aff0c73a2e76accaf518321fc9) 1110# 06 pc 0000000000007564 /system/lib64/module/events/libemitter.z.so(OHOS::AppExecFwk::SearchCallbackInfo(napi_env__*, std::__h::variant<unsigned int, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>>> const&, napi_value__*)+248)(8fe2937855aab3ea839419f952597511) 1111# 07 pc 0000000000007d8c /system/lib64/module/events/libemitter.z.so(OHOS::AppExecFwk::OnOrOnce(napi_env__*, napi_callback_info__*, bool)+568)(8fe2937855aab3ea839419f952597511) 1112# 08 pc 00000000000096d8 /system/lib64/module/events/libemitter.z.so(OHOS::AppExecFwk::JS_Once(napi_env__*, napi_callback_info__*) (.cfi)+84)(8fe2937855aab3ea839419f952597511) 1113# 09 pc 000000000002c8f0 /system/lib64/platformsdk/libace_napi.z.so(ArkNativeFunctionCallBack(panda::JsiRuntimeCallInfo*)+168)(c3a760aff0c73a2e76accaf518321fc9) 1114# 10 pc 0000000000187b48 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40) 1115# 11 pc 00000000002da5fc /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::InterpreterAssembly::Execute(panda::ecmascript::EcmaRuntimeCallInfo*)+416)(7715646e48f750f3dc31e660b056eb43) 1116# 12 pc 00000000002da5fc /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::InterpreterAssembly::Execute(panda::ecmascript::EcmaRuntimeCallInfo*)+416)(7715646e48f750f3dc31e660b056eb43) 1117# 13 pc 00000000003954a0 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::JSStableArray::HandleforEachOfStable(panda::ecmascript::JSThread*, panda::ecmascript::JSHandle<panda::ecmascript::JSObject>, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue>, panda::ecmascript::JSHandle<panda::ecmascript::JSTaggedValue>, unsigned int, unsigned int&)+596)(7715646e48f750f3dc31e660b056eb43) 1118# 14 pc 000000000018f4b0 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::builtins::BuiltinsArray::ForEach(panda::ecmascript::EcmaRuntimeCallInfo*)+840)(7715646e48f750f3dc31e660b056eb43) 1119... 1120``` 1121 1122Check the Hilog logs. 1123 1124The **APP_INPUT_BLOCK** event is reported at about **13:40:59.448**, and then the DFX kills the suspended SCB. 1125 1126 1127 11286 seconds before, a click event was sent to the SCB at about **14:40:53.498**. 1129 1130 1131 1132Within the 6 seconds, a large number of SCB logs are printed, showing that the SCB is re-rendering. 1133 1134 1135 1136Check the trace log within the 6 seconds. 1137 1138 1139 1140It shows that the SCB main thread is fully occupied. The **CustomNodeUpdate SwiperPage** task takes a longer time. Therefore, you need to check why this component keeps refreshing. 1141 1142It is found that **themeStyle** is added to the **key** on **swiperPage**. When the **key** value changes, a new control is created. 1143 1144When a user switches the theme or icon style, all controls on the home screen are created. As a result, the main thread is busy and cannot respond the input event. 1145 1146#### Solution 1147 1148Trigger the home screen component refresh only when the home screen component style is switched, and narrow down the refresh scope. 1149 1150```ts 1151+ if (!CheckEmptyUtils.isEmpty(themeStyleInfo.iconResourcePath) && 1152+ themeStyleInfo.iconResourcePath !== this.themeStyle.iconResourcePath) { 1153+ this.isStyleChanged = true; 1154+ this.themeStyle.iconResourcePath = themeStyleInfo.iconResourcePath; --> themeStyle is associated with iconResourcePath. 1155+ } 1156``` 1157 1158#### Suggestions 1159 1160The scope of page refresh triggered by a click event needs to be properly controlled. Avoid scenarios such as a large number of components need to be refreshed or a page needs to be refreshed frequently. 1161 1162### Typical Case of **LIFECYCLE_TIMEOUT** - Loading a Cloud Diagram 1163 1164#### Background 1165 1166When a user opens a cloud note, the application freezes and then crashes. 1167 1168#### Error Codes 1169 1170The cloud images are obtained synchronously in a loop. 1171 1172```ts 1173public static xxxFunction(fileUris: string[]): void { 1174 ... 1175 for (const fileuril of fileUrils) { 1176 let file = fs.openSync(fileUri, fs.OpenMode.READ_ONLY); 1177 ... 1178 } 1179 ... 1180} 1181``` 1182 1183#### Impact 1184 1185The application freezes and crashes when it is started or switched to the foreground. 1186 1187#### Fault Locating 1188 1189The following example extracts the key fault logs of **LIFECYCLE_TIMEOUT** that occurs in notepad. 1190 1191``` 1192 sysfreeze: LIFECYCLE_TIMEOUT LIFECYCLE_TIMEOUT at 20240201100459 1193``` 1194 1195The **MSG** information indicates that the timeout is in the foreground, and the duration is 5s. 1196 1197``` 1198MSG = 1199Fault time:2024/02/01-10:04:57 1200ability:MainAbility foreground timeout. 1201server: 1202312522; AbilityRecord::ForegroundAbility; the ForegroundAbility lifecycle starts. 1203client: 1204312522; AbilityThread::ScheduleAbilityTransaction; the foreground lifecycle. 1205``` 1206 1207The **LIFECYCLE_HALF_TIMEOUT** event is reported at **10:04:57:538**. 1208The **LIFECYCLE_TIMEOUT** event is reported at **10:04:59:965**. The interval of the two events is about 2.5s, which is as expected. 1209 1210``` 1211>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1212DOMAIN:AAFWK 1213STRINGID:LIFECYCLE_TIMEOUT 1214TIMESTAMP:2024/02/01-10:04:59:965 1215PID:18083 1216UID:20020041 1217PACKAGE_NAME:com.huawei.hmos.notepad 1218PROCESS_NAME:com.huawei.hmos.notepad 1219******************************************* 1220start time: 2024/02/01-10:04:57:555 1221DOMAIN = AAFWK 1222EVENTNAME = LIFECYCLE_HALF_TIMEOUT 1223TIMESTAMP = 2024/02/01-10:04:57:538 1224PID = 18083 1225UID = 20020041 1226TID = 17286 1227PACKAGE_NAME = com.huawei.hmos.notepad 1228PROCESS_NAME = com.huawei.hmos.notepad 1229``` 1230 1231The task is started at **10:04:54.798**, and the interval between the start time and **LIFECYCLE_HALF_TIMEOUT** is about 2.5s, which is as expected. 1232 1233``` 1234mainHandler dump is: 1235 EventHandler dump begin curTime: 2024-02-01 10:04:57.306 1236 Event runner (Thread name = , Thread ID = 18083) is running 1237 Current Running: start at 2024-02-01 10:04:54.798, Event { send thread = 18132, send time = 2024-02-01 10:04:54.778, handle time = 2024-02-01 10:04:54.778, task name = UIAbilityThread:SendResult } 1238 History event queue information: 1239 No. 0 : Event { send thread = 18083, send time = 2024-02-01 10:04:46.481, handle time = 2024-02-01 10:04:46.981, trigger time = 2024-02-01 10:04:46.982, completeTime time = 2024-02-01 10:04:46.982, task name = } 1240 No. 1 : Event { send thread = 18132, send time = 2024-02-01 10:04:47.149, handle time = 2024-02-01 10:04:47.149, trigger time = 2024-02-01 10:04:47.149, completeTime time = 2024-02-01 10:04:47.197, task name = MainThread:BackgroundApplication } 1241 No. 2 : Event { send thread = 18083, send time = 2024-02-01 10:04:44.329, handle time = 2024-02-01 10:04:47.329, trigger time = 2024-02-01 10:04:47.329, completeTime time = 2024-02-01 10:04:47.329, task name = } 1242 No. 3 : Event { send thread = 18087, send time = 2024-02-01 10:04:48.091, handle time = 2024-02-01 10:04:48.091, trigger time = 2024-02-01 10:04:48.091, completeTime time = 2024-02-01 10:04:48.091, task name = } 1243 No. 4 : Event { send thread = 18087, send time = 2024-02-01 10:04:51.047, handle time = 2024-02-01 10:04:51.047, trigger time = 2024-02-01 10:04:51.048, completeTime time = 2024-02-01 10:04:51.048, task name = } 1244 No. 5 : Event { send thread = 18087, send time = 2024-02-01 10:04:54.067, handle time = 2024-02-01 10:04:54.067, trigger time = 2024-02-01 10:04:54.067, completeTime time = 2024-02-01 10:04:54.067, task name = } 1245 ... 1246``` 1247 1248Check the stack information at **libfs.z.so -> libdatashare_consumer.z.so -> libipc_core.z.so**. 1249 1250``` 1251Tid:18083, Name:ei.hmos.notepad 1252# 00 pc 00000000001617a4 /system/lib/ld-musl-aarch64.so.1(ioctl+180)(4ca73cff61bea7c4a687eb0f71c9df69) 1253# 01 pc 000000000003e8a0 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderConnector::WriteBinder(unsigned long, void*)+72)(3248fceb1fa676994734e0437430ce37) 1254# 02 pc 0000000000049f38 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::TransactWithDriver(bool)+296)(3248fceb1fa676994734e0437430ce37) 1255# 03 pc 00000000000496f8 /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::WaitForCompletion(OHOS::MessageParcel*, int*)+116)(3248fceb1fa676994734e0437430ce37) 1256# 04 pc 00000000000490bc /system/lib64/platformsdk/libipc_core.z.so(OHOS::BinderInvoker::SendRequest(int, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+312)(3248fceb1fa676994734e0437430ce37) 1257# 05 pc 0000000000027700 /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequestInner(bool, unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+132)(3248fceb1fa676994734e0437430ce37) 1258# 06 pc 000000000002799c /system/lib64/platformsdk/libipc_core.z.so(OHOS::IPCObjectProxy::SendRequest(unsigned int, OHOS::MessageParcel&, OHOS::MessageParcel&, OHOS::MessageOption&)+140)(3248fceb1fa676994734e0437430ce37) 1259# 07 pc 000000000002640c /system/lib64/platformsdk/libdatashare_consumer.z.so(OHOS::DataShare::DataShareProxy::OpenFile(OHOS::Uri const&, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+440)(e93b5085235269d4b7218ea7de64b69a) 1260# 08 pc 0000000000014b2c /system/lib64/platformsdk/libdatashare_consumer.z.so(OHOS::DataShare::ExtSpecialController::OpenFile(OHOS::Uri const&, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+160)(e93b5085235269d4b7218ea7de64b69a) 1261# 09 pc 0000000000022c54 /system/lib64/platformsdk/libdatashare_consumer.z.so(OHOS::DataShare::DataShareHelperImpl::OpenFile(OHOS::Uri&, std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&)+96)(e93b5085235269d4b7218ea7de64b69a) 1262# 10 pc 0000000000108b34 /system/lib64/module/file/libfs.z.so(OHOS::FileManagement::ModuleFileIO::OpenFileByDatashare(std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&, unsigned int)+468)(152580bf9c379f11f29fdded278541bd) 1263# 11 pc 0000000000108264 /system/lib64/module/file/libfs.z.so(OHOS::FileManagement::ModuleFileIO::OpenFileByUri(std::__h::basic_string<char, std::__h::char_traits<char>, std::__h::allocator<char>> const&, unsigned int)+1760)(152580bf9c379f11f29fdded278541bd) 1264# 12 pc 00000000001077fc /system/lib64/module/file/libfs.z.so(OHOS::FileManagement::ModuleFileIO::Open::Sync(napi_env__*, napi_callback_info__*) (.cfi)+1036)(152580bf9c379f11f29fdded278541bd) 1265# 13 pc 000000000002bbf8 /system/lib64/platformsdk/libace_napi.z.so(ArkNativeFunctionCallBack(panda::JsiRuntimeCallInfo*)+168)(f5b81db475835ee752235c606b1c5e33) 1266# 14 pc 0000000000132e48 /system/lib64/module/arkcompiler/stub.an 1267``` 1268 1269The **BinderCatcher** shows that the communication with process **5235** takes more than 2.5s, which is as expected. 1270 1271``` 1272PeerBinderCatcher -- pid==18083 layer_ == 1 1273BinderCatcher -- 1274 18083:18083 to 5235:7437 code 2 wait:2.723147396 s 1275 3462:3840 to 4956:4958 code 8 wait:261.213830169 s 1276 3462:3621 to 4956:4981 code 8 wait:273.550283291 s 1277``` 1278 1279The **5235** is a media library process and stack information is not useful for analysis. 1280 1281``` 1282PeerBinder Stacktrace -- 1283PeerBinderCatcher start catcher stacktrace for pid : 5235 1284Result: 0 ( no error ) 1285Timestamp:2024-02-01 10:04:57.000 1286Pid:5235 1287Uid:20020079 1288Process name:com.ohos.medialibrary.medialibrarydata 1289Tid:5235, Name:edialibrarydata 1290# 00 pc 0000000000142d1c /system/lib/ld-musl-aarch64.so.1(epoll_wait+84)(4ca73cff61bea7c4a687eb0f71c9df69) 1291# 01 pc 000000000000fb74 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EpollIoWaiter::WaitFor(std::__h::unique_lock<std::__h::mutex>&, long)+224)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1292# 02 pc 0000000000019df8 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventQueue::WaitUntilLocked(std::__h::chrono::time_point<std::__h::chrono::steady_clock, std::__h::chrono::duration<long long, std::__h::ratio<1l, 1000000000l>>> const&, std::__h::unique_lock<std::__h::mutex>&)+180)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1293# 03 pc 0000000000019c6c /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventQueue::GetEvent()+128)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1294# 04 pc 00000000000202b8 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::(anonymous namespace)::EventRunnerImpl::Run()+1164)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1295# 05 pc 0000000000022388 /system/lib64/chipset-pub-sdk/libeventhandler.z.so(OHOS::AppExecFwk::EventRunner::Run()+120)(a4d21072c08fd3ac639d5cf5b8fb8b51) 1296# 06 pc 000000000007ea08 /system/lib64/platformsdk/libappkit_native.z.so(OHOS::AppExecFwk::MainThread::Start()+772)(183fe2babcfdd3e1ea4bca16a0e26a5d) 1297# 07 pc 0000000000011ac8 /system/bin/appspawn(RunChildProcessor+236)(7b715884c45cfe57b22df46fdaeeca88) 1298# 08 pc 0000000000034684 /system/bin/appspawn(AppSpawnChild+264)(7b715884c45cfe57b22df46fdaeeca88) 1299# 09 pc 00000000000344f4 /system/bin/appspawn(AppSpawnProcessMsg+380)(7b715884c45cfe57b22df46fdaeeca88) 1300# 10 pc 00000000000305a0 /system/bin/appspawn(OnReceiveRequest+1820)(7b715884c45cfe57b22df46fdaeeca88) 1301# 11 pc 0000000000017c58 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(HandleRecvMsg_+260)(22f33d1b0218f31bad0dcc75cf348b90) 1302# 12 pc 00000000000178fc /system/lib64/chipset-pub-sdk/libbegetutil.z.so(HandleStreamEvent_+148)(22f33d1b0218f31bad0dcc75cf348b90) 1303# 13 pc 0000000000015478 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(ProcessEvent+112)(22f33d1b0218f31bad0dcc75cf348b90) 1304# 14 pc 0000000000015090 /system/lib64/chipset-pub-sdk/libbegetutil.z.so(RunLoop_+308)(22f33d1b0218f31bad0dcc75cf348b90) 1305# 15 pc 000000000002eff4 /system/bin/appspawn(AppSpawnRun+116)(7b715884c45cfe57b22df46fdaeeca88) 1306# 16 pc 000000000001f438 /system/bin/appspawn(main+724)(7b715884c45cfe57b22df46fdaeeca88) 1307# 17 pc 00000000000a0974 /system/lib/ld-musl-aarch64.so.1(libc_start_main_stage2+64)(4ca73cff61bea7c4a687eb0f71c9df69) 1308# 18 pc 000000000001106c /system/bin/appspawn(_start_c+76)(7b715884c45cfe57b22df46fdaeeca88) 1309``` 1310 1311The preceding information indicates that the application loads files synchronously using the URI through **Open::Sync** and calls the **datashare()** to obtain media library file data. 1312 1313The log information shows that the process is suspended when calls the **datashare()** to load the cloud diagram, which is consistent with the stack information. 1314 1315 1316 1317Check the code: 1318 1319It is unreasonable to load **fileUri** synchronously in a loop. When the network is weak or a large amount of data is loaded at the same time, the application tends to be suspended. In this case, the application need to be modified. 1320 1321#### Solution 1322 1323Change the synchronous loading to asynchronous loading, use a flag to indicate whether the loading is complete and display the loading effect on the GUI. 1324 1325```ts 1326public static xxxFunction(fileUris: string[]): void { 1327 ... 1328 for (const fileuril of fileUrils) { 1329 let file = fs.openSync(fileUri, fs.OpenMode.READ_ONLY); 1330 ... 1331 } 1332 ... 1333} 1334``` 1335 1336Change the preceding codes as follows: 1337 1338```ts 1339public static async xxxFunction(fileUris: string[]): void { 1340 ... 1341 AppStorage.setOrCreate<boolean>('isLoadingPic', true); --> This function is used to display the page load effect. 1342 for (const fileuril of fileUrils) { 1343 let file = await fs.open(fileUri, fs.OpenMode.READ_ONLY); 1344 ... 1345 } 1346 ... 1347} 1348``` 1349 1350#### Suggestions 1351 13521. Data on the cloud side must be fully verified in scenarios with good network, weak network, and no network. 1353 13542. Do not perform time-consuming operations in the application lifecycle function. 1355
