同步操作将从 OpenHarmony/docs 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
When the system is suspended unexpectedly, information about key registers is displayed on the serial port, as shown in the following figure. The information can be used to locate the function where the exception occurs and the related call stack.
Figure 1 Exception information
The exception information in the preceding figure is described as follows:
①: indicates that the exception is in kernel mode.
②: indicates the exception type. The value of far is the address accessed by the CPU when the exception occurs.
③: The pc value indicates the location of the instruction being executed when the exception occurs. The klr value indicates the next instruction to be executed. (Note: You do not need to pay attention to the value of klr if traceback 0 lr in ④ has a value.)
④: The lr values indicate the locations of the instructions to be executed by the program counter in sequence in normal cases.
You also need to check the OHOS_Image.asm file (assembly file corresponding to the burnt system image OHOS_Image.bin) in the out directory to determine the locations of the instructions corresponding to pc and lr. Based on the locations of the instructions, determine the functions using the instructions and the functions where lrs are located in sequence. In this way, you can obtain the function call relationships when the exception occurs.
You may not directly locate the fault only with the exception information. Sometimes, the fault cannot be located due to incorrect register values. If you suspect that the fault is caused by heap memory overwriting, you can call LOS_MemIntegrityCheck to check the memory pool integrity. The LOS_MemIntegrityCheck function traverses all nodes in the dynamic memory pool of the system. If all nodes are normal, the function returns 0 and no information is printed. Otherwise, error information is printed. This function uses (VOID *)OS_SYS_MEM_ADDR as the input parameter.
Generally, LOS_MemIntegrityCheck is called before and after the suspected service logic code to locate the heap memory overwriting. If the service code is correct, LOS_MemIntegrityCheck can be called successfully. By doing this, you can improve the troubleshooting efficiency.
If the memory of a global variable is illegally accessed, locate the address of the global variable in the OHOS_Image.map file and pay special attention to the variables recently used before the address. There is a high probability that memory overwriting occurs when the preceding variables (especially variables of the array type or variables that are forcibly converted to other types) are used.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。