1# JS Crash (Process Crash) Detection 2<!--Kit: Performance Analysis Kit--> 3<!--Subsystem: HiviewDFX--> 4<!--Owner: @wanghuan2025--> 5<!--Designer: @Maplestory--> 6<!--Tester: @yufeifei--> 7<!--Adviser: @foryourself--> 8 9## Overview 10 11Crash detection is an important monitoring capability in ArkTS applications, which helps you detect and fix problems in applications in a timely manner. 12 13 14## Detection Principles 15 16When an application exits unexpectedly due to an uncaught exception or error during code execution, it crashes at the point the unhandled exception is thrown, generates a corresponding JS crash log file, and reports the crash event. You can use HiAppEvent to subscribe to [crash events](hiappevent-watcher-crash-events.md). For details about how to analyze JS crash issues, see [Analyzing JS Crashes](https://developer.huawei.com/consumer/en/doc/best-practices/bpta-stability-app-crash-js-way) 17 18 19## Constraints 20 21If an exception is thrown in an asynchronous function, no JS crash will occur. You can observe the exception through [ErrorManager](../reference/apis-ability-kit/js-apis-app-ability-errorManager.md#errormanageronerror). 22 23 24## Obtaining Logs 25 26Process crash logs are fault logs managed by the FaultLogger module. You can obtain the logs in any of the following ways: 27 28**Method 1: DevEco Studio** 29 30DevEco Studio collects process crash logs from **/data/log/faultlog/faultlogger/** to FaultLog, where logs are displayed by process name, fault, and time. For details about how to obtain logs, see [Fault Log](https://developer.huawei.com/consumer/en/doc/harmonyos-guides/ide-fault-log). 31 32**Method 2: HiAppEvent APIs** 33 34HiAppEvent provides APIs for subscribing to faults. For details, see [Introduction to HiAppEvent](hiappevent-intro.md). You can subscribe to the crash event by referring to [Subscribing to Crash Events (ArkTS)](hiappevent-watcher-crash-events-arkts.md) or [Subscribing to Crash Events (C/C++)](hiappevent-watcher-crash-events-ndk.md), and then read the fault log file content based on the [external_log](hiappevent-watcher-crash-events.md#fields) field of the event. 35 36**Method 3: hdc** 37 38When **Developer options** is enabled, you can run the following command to obtain logs to the local host: 39```text 40hdc file recv /data/log/faultlog/faultlogger Local path. 41``` 42The fault log file name format is **jscrash-Process name-Process UID-Millisecond-level time .log**. 43 44 45## Log Specifications 46 47 48Example of the JS crash log specifications: 49```text 50Device info:XXX <- Device information 51Build info:XXX-XXXX X.X.X.XX(XXXXXXXX) <- Build information 52Fingerprint:ed1811f3f5ae13c7262b51aab73ddd01df95b2c64466a204e0d70e6461cf1697 <- Fault features 53Timestamp:XXXX-XX-XX XX:XX:XX.XXX <- Timestamp 54Module name:com.example.myapplication <- Bundle name/Process name 55Version:1.0.0 <- HAP version 56VersionCode:1000000 <- Version code 57Pid:579 <- Faulty process ID 58Uid:0 <- User ID 59Process Memory(kB): 1897(Rss) <- Process memory usage 60Device Memory(kB): Total 1935820, Free 482136, Available 1204216 <- Device memory information 61Reason:TypeError <- Fault cause 62Error name:TypeError <- Fault type 63Error message:Cannot read property c of undefined <- Error message 64Cannot get SourceMap info, dump raw stack: <- The release package does not contain the **SourceMap** file, and the JS stack fails to parse it. 65Stacktrace: 66 at onPageShow entry (entry/src/main/ets/pages/Index.ets:7:13) <- Call stack of the exception code 67 ^ ^ ^ 68 Function name Module package name The row and column numbers in the file 69 70HiLog: 71 ^ 72 Add 1000 lines of HiLog logs related to the exception to the generated crash log file. 73 74``` 75 76 77JS crashes are classified into the following types in the **Reason** field based on exception scenarios: 78 79 80- **Error**: The most basic error type. Other error types are inherited from this type. The **Error** object has two important attributes: **Error message** and **Error name**. Generally, exceptions of the **Error** type are thrown by developers. 81 82- **TypeError**: The most common error type at runtime, indicating a variable or parameter that is not of the expected type. 83 84- **SyntaxError**: Parsing error, indicating that the syntax does not comply with the syntax specifications of the programming language. 85 86- **RangeError**: Exception thrown when a value exceeds the valid range. Common range errors include the following: 87 88 - The length of an array is negative or exceeds the maximum length. 89 - The numeric parameter exceeds the predefined range. 90 - The function stack call depth exceeds the upper limit. 91 92- **ReferenceError**: Error thrown when a variable that does not exist is referenced. Each time a variable is created, the variable name and its value are stored in the key-value format. When a variable is referenced, the value will be located based on the key and returned. If the variable referenced cannot be found, **ReferenceError** is thrown. 93 94- **URI Error**: Error occurs when the format of a URL, URN, or other resource identifier is incorrect or the operation is invalid. The following functions are involved: **encodeURI()**, **decodeURI()**, **encodeURIComponent()**, **decodeURIComponent()**, **escape()**, and **unescape()**. 95 96- **OOMError**: Error occurs when the heap memory is insufficient and cannot be allocated for new objects. 97 98- **TerminationError**: Error occurs when the process is forcibly terminated. For example, if there are tasks that are executed for a long time or have an infinite loop in the Taskpool thread, the process is forcibly terminated and this error is reported. 99 100- **AggregateError**: Error occurs when there are multiple errors. It is used in scenarios where multiple errors need to be processed or reported. 101 102- **EvalError**: Error occurs when the **eval()** function execution is abnormal. However, in practice, this error type is rarely used. The engine usually throws **SyntaxError** or **TypeError**. 103 104 105You can identify the cause of the JS crash, mostly application issues, based on **Error message** and **Stacktrace** in the logs. 106 107 108### Exception Code Call Stack Formats 109 110 111The exception code call stack content in release mode is different from that in debug mode. In debug mode, the complete debugging information is retained. In release mode, debugging information is stripped through code optimization and obfuscation. 112 113 114**Release mode** 115 116 117In an application built in release mode, the standard format of exception stack information is as follows: 118 119 120at \<Execution method name> (\<Module name|Dependent module name|Version number|Compilation product path>:\<Line number>:\<Column number>) 121 122 123The following is an example: 124 125 126``` 127at onPageShow (entry|har1|1.0.0|src/main/ets/pages/Index.ts:7:13) 128``` 129 130 131Format description: 132 133 1341. **at**: fixed start identifier of the stack call chain. 135 1362. Execution method name: **onPageShow** indicates the name of the calling method that triggers an exception. 137 1383. The structure of the compilation product is as follows: 139 - Compilation product path: For details, see [Sourcemap Format](https://developer.huawei.com/consumer/en/doc/harmonyos-guides/ide-exception-stack-parsing-principle#section1145914292713). 140 - File type: The file name extension is **.ts**. (For .js files, the exception can be located directly without SourceMap mapping.) 141 1424. Row and column number: Colons (:\) are used to separate row and column numbers of the exception. 143 144 145**Debug mode** 146 147 148In an application built in debug mode or a release application whose exception stack is translated using source map, the standard exception stack information format is as follows: 149 150 151at \<Execution method name> \<Dependent module name> (\<Source code path>:\<Line number>:\<Column number>) 152 153 154The following is an example: 155 156 157``` 158at onPageShow har1 (har1/src/main/ets/pages/Index.ets:7:13) 159``` 160 161 162Format description: 163 164 1651. **at**: fixed start identifier of the stack call chain. 166 1672. Execution method name: **onPageShow** indicates the name of the calling method that triggers an exception. 168 1693. Dependent module name: **har1** indicates the name of the module to which the source code path belongs. 170 1714. The source code path structure is as follows: 172 - Source code path: Source code file path based on the project directory. 173 - File type: The file name extension is **.ets**. 174 1755. Row and column number: Colons (:\) are used to separate row and column numbers of the exception. 176