1# cppcrash Log Analysis 2 3## Introduction 4 5A process crash refers to a C/C++ runtime crash. The FaultLogger module of OpenHarmony provides capabilities such as process crash detection, log collection, log storage, and log reporting, helping you to locate faults more effectively. 6 7In this document, you'll be guided through how to implement process crash detection, crash log collection, and crash log analysis. Before getting started, make sure you have basic knowledge about C/C++ program stacks. 8 9## Process Crash Detection 10 11Process crash detection is implemented based on the Linux signal mechanism. Currently, C/C++ crash exception signals listed in the following table are supported. 12 13| Signal Value| Signal| Description| Trigger Cause| 14| ------ | --------- | --------------- | ------------------------------------------- | 15| 4 | SIGILL | Invalid instruction | An invalid, incorrectly formatted, unknown, or privileged instruction is executed.| 16| 5 | SIGTRAP | Breakpoint or trap | An exception occurs or a trap instruction is executed.| 17| 6 | SIGABRT | Process abort | The process is aborted abnormally. Generally, this problem occurs if the process calls the `abort()` function of the standard function library.| 18| 7 | SIGBUS | Illegal memory access | The process accesses an aligned or nonexistent physical address.| 19| 8 | SIGFPE | Floating-point exception | The process performs an incorrect arithmetic operation, for example, a 0 divisor, floating point overflow, or integer overflow.| 20| 11 | SIGSEGV | Invalid memory access | The process accesses an invalid memory reference.| 21| 16 | SIGSTKFLT | Stack error | The processor performs an incorrect stack operation, such as a pop when the stack is empty or a push when the stack is full.| 22| 31 | SIGSYS | Incorrect system call | An incorrect or invalid parameter is used in a system call.| 23 24## Crash Log Collection 25 26Process crash log is the fault log managed together with the app freeze and JS application crash logs by the FaultLogger module. You can collect process crash logs in any of the following ways: 27 28### Collecting Logs by Using Shell 29 30- Fault logs in the `/data/log/faultlog/faultlogger/` directory of the device. The log files are named in the format of `cppcrash-process name-process UID-time (seconds level)`. They contain only information such as the device name, system version, and process crash call stack. 31 32  33 34- Fault logs in the `/data/log/faultlog/temp/` directory of the device. The log files are named in the format of `cppcrash-process name-process PID-system timestamp (seconds level)`. In addition to basic information, they also contain information such as the stack memory and process maps at the time of process crash. 35 36  37 38### Collecting Logs by Using DevEco Studio 39 40DevEco Studio collects process crash logs from `/data/log/faultlog/faultlogger/` to FaultLog, where logs are displayed by process name, fault, and time. 41 42 43 44### Collecting Logs by Using faultLogger APIs 45 46The FaultLogger module provides APIs to query various fault information. For details, see [@ohos.faultLogger](../reference/apis/js-apis-faultLogger.md). 47 48## Process Crash Log Analysis 49 50### Log Format 51 52The following is an example process crash log archived by DevEco Studio in FaultLog: 53 54``` 55Generated by HiviewDFX@OpenHarmony 56================================================================== 57Device info:OpenHarmony 3.2 <- Device information 58Build info:OpenHarmony 4.0.5.5 <- Version information 59Module name:crasher_c <- Module name 60Pid:1205 <- Process ID 61Uid:0 <- User ID 62Reason:Signal:SIGSEGV(SEGV_ACCERR)@0x0042d33d <- Exception information 63Thread name:crasher <- Abnormal thread 64#00 pc 0000332c /data/crasher(TriggerSegmentFaultException+15)(8bc37ceb8d6169e919d178fdc7f5449e) <- Call stack 65#01 pc 000035c7 /data/crasher(ParseAndDoCrash+277)(8bc37ceb8d6169e919d178fdc7f5449e) 66#02 pc 00003689 /data/crasher(main+39)(8bc37ceb8d6169e919d178fdc7f5449e) 67#03 pc 000c3b08 /system/lib/ld-musl-arm.so.1(__libc_start_main+116) 68#04 pc 000032f8 /data/crasher(_start_c+112)(8bc37ceb8d6169e919d178fdc7f5449e) 69#05 pc 00003284 /data/crasher(_start+32)(8bc37ceb8d6169e919d178fdc7f5449e) 70... 71``` 72 73### Locating Faults Through Logs 74 751. Determine the faulty module and fault type based on fault logs. 76 77 Generally, you can identify the faulty module based on the crash process name and identify the crash cause based on the signal. Besides, you can restore the function call chain of the crash stack based on the method name in the stack. 78 79 In the example, **SIGSEGV** is thrown by the Linux kernel because of access to an invalid memory address. The problem occurs in the **TriggerSegmentFaultException** function. 80 81 In most scenarios, a crash is caused by the top layer of the crash stack, such as null pointer access and proactive program abort. 82 83 If the cause cannot be located through the call stack, you need to check for other faults, for example, memory corruption or stack overflow. 84 852. Use the addr2line tool of Linux to parse the code line number to restore the call stack at the time of process crash. 86 87 When using the addr2line tool to parse the code line number of the crash stack, make sure that binary files with debugging information is used. Generally, such files are generated during version build or application build. 88 89 Application binary files are located in DevEco Studio's temporary directory for application build, for example, `build/default/intermediates/libs`. 90 91 System binary files are stored in the directories listed below. For versions that are directly obtained, the binary files are archived in the image package. 92 ``` 93 \code root directory\out\product\lib.unstripped 94 \code root directory\out\product\exe.unstripped 95 ``` 96 97 You can run `apt-get install addr2line` to install the addr2line tool on Linux. 98 99 On On DevEco Studio, you can also use the llvm-addr2line tool archived in the SDK to parse code line numbers. The usage method is the same. 100 101 The following example shows how to use the addr2line tool to parse the code line number based on the offset address: 102 103 ``` 104 root:~/OpenHarmony/out/rk3568/exe.unstripped/hiviewdfx/faultloggerd$ addr2line -e crasher 0000332c 105 base/hiviewdfx/faultloggerd/tools/crasher/dfx_crasher.c:57 106 ``` 107 108 In this example, the crash is caused by assignment of a value to an unwritable area. It is in code line 57 in the **dfx_crasher.c** file. You can modify it to avoid the crash. 109 110 If the obtained code line number is seemingly incorrect, you can fine-tune the address (for example, subtract the address by 1) or disable some compilation optimization items. It is known that the obtained code line number may be incorrect when Link Time Optimization (LTO) is enabled. 111
