An exception processing method, an exception processing system, and an electronic device

Abstract

Embodiments of the present application apply to the technical field of terminals, and provide an exception handling method, an exception handling system and an electronic device. In a case where it is detected that a target subsystem has an abnormal crash, the electronic device can acquire fault information and call stack information. The fault information represents instruction information when the target subsystem has the abnormal crash. The call stack information is used to represent a hierarchical calling relationship between the target fault instruction and at least one historical fault instruction. The fault information and the call stack information are used to locate a cause of the abnormal crash of the target subsystem. Then, the target subsystem in the electronic device can perform a restart operation. In the present application, accurate positioning of a restart cause can be implemented.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to an exception handling method, an exception handling system, and an electronic device. Background Technology

[0002] With the continuous development of electronic devices, such as mobile phones, they have gradually become an indispensable part of people's daily lives. However, during the operation of electronic devices, if a subsystem malfunctions, it may cause the subsystem to restart, thus affecting the user experience.

[0003] Therefore, accurately identifying the cause of restarts in order to expedite the resolution of abnormal restart issues is an urgent problem to be solved. Summary of the Invention

[0004] This application provides an exception handling method, an exception handling system, and an electronic device to accurately locate the cause of a restart, thereby accelerating the resolution of abnormal restart problems.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, an exception handling method is provided for an electronic device. In this method, upon detecting an abnormal crash in a target subsystem, the electronic device can obtain fault information and call stack information. The fault information represents the instruction information at the time of the abnormal crash in the target subsystem. The call stack information represents the hierarchical call relationship between the target fault instruction and at least one historical fault instruction. The fault information and call stack information are used to locate the cause of the abnormal crash in the target subsystem. Afterward, the target subsystem in the electronic device can perform a restart operation.

[0007] The aforementioned fault information includes at least one of the following: target task name, target fault event, location information of the target fault instruction, and return address of the target fault instruction. The target task name is the name of the task executed when the target subsystem experiences an abnormal crash. The target fault event characterizes the abnormal situation caused by the abnormal crash of the target subsystem. The return address of the target fault instruction is the address invoked when the target fault instruction is executed.

[0008] The aforementioned call stack information may include the return address of at least one historical instruction. This return address is used to characterize the call relationship between the historical instruction and the target fault instruction.

[0009] In this embodiment, after detecting an abnormal crash in the target subsystem, the electronic device not only obtains fault information but also call stack information. It can combine the call stack information to determine the call relationship between the target fault instruction and historical instructions, and then determine the root cause of the abnormal crash in the target subsystem based on the call relationship. This achieves precise location of the restart cause, which not only improves the convergence efficiency of the abnormal restart problem of the target subsystem but also facilitates the timely resolution of the abnormal restart problem by R&D personnel, providing a foundation for reducing the probability of abnormal restart problems in the future.

[0010] In one possible implementation of the first aspect, the method further includes: the electronic device sending fault information and call stack information to the server.

[0011] In this embodiment, after receiving fault information and call stack information from the electronic device, the server can store the fault information and call stack information. This allows developers to easily determine the call relationship between the target fault instruction and historical instructions by combining the call stack information. Based on this call relationship, they can then determine the root cause of the abnormal crash in the target subsystem, achieving precise location of the restart cause. This not only improves the convergence efficiency of addressing abnormal restart issues in the target subsystem but also facilitates timely resolution of the abnormal restart problem by developers, laying the foundation for reducing the probability of subsequent abnormal restarts.

[0012] In one possible implementation of the first aspect, the aforementioned electronic device further includes an application processor running a first operating system. The process by which the electronic device acquires fault information and call stack information may specifically include: after detecting an abnormal crash, the target subsystem generates fault information and call stack information. Subsequently, the target subsystem may send the fault information and call stack information to the application processor.

[0013] In this embodiment of the application, after the target subsystem detects an abnormal crash, it can send the generated fault information and call stack information to the application processor, so that the application processor can send the fault information and call stack information to the server, which provides convenient conditions for accurate location of the cause of the subsequent restart.

[0014] In one possible implementation of the first aspect, the process by which the target subsystem generates fault information and call stack information may specifically include: after detecting an abnormal crash, the target subsystem obtains target register information, including the abnormal process ID. Then, the target subsystem can determine whether the abnormal process ID is the same as the target process ID. If they are the same, the target subsystem can execute the error handling procedure of the root process domain. The target process ID represents the process currently running in the target subsystem. The error handling procedure of the root process domain generates fault information and call stack information, and enables the application processor to obtain the fault information and call stack information from shared memory.

[0015] The target register information also includes the target task name, the location information of the target fault instruction, and the return address of the target fault instruction.

[0016] In this embodiment, if the abnormal process ID in the target register information is the same as the target process ID, it indicates that the abnormal process ID belongs to the root process ID (PD), meaning that the fault belongs to the entire target subsystem. Therefore, the target subsystem can execute the error handling process of the root process domain. This not only improves the convenience of information acquisition but also reduces the occurrence of call stack information loss due to a restart of the entire target subsystem, improving the storage capacity of call stack information and providing convenient conditions for accelerating the subsequent investigation of restart problems.

[0017] In one possible implementation of the first aspect, the process by which the target subsystem executes the error handling flow of the root process domain may specifically include: the target subsystem obtaining the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, and obtaining the target fault event from the target information. Here, the target information is the error information recorded by the target subsystem when an abnormal crash occurs. Afterwards, the target subsystem may perform a call stack backtracking operation and generate call stack information. Then, the target subsystem may save the fault information and call stack information to shared memory. Next, the target subsystem may send a target interrupt signal to the application processor. Here, the target interrupt signal indicates that the entire target subsystem needs to be restarted. Afterwards, upon receiving the target interrupt signal sent by the target subsystem, the application processor obtains the fault information and call stack information from shared memory.

[0018] In this embodiment, the application processor can obtain fault information and call stack information from shared memory and report the fault information and call stack information to the server so as to locate the root cause of the abnormal crash of the target subsystem based on the fault information and call stack information. In other words, it achieves accurate location of the restart cause, which not only improves the convergence efficiency of the abnormal restart problem of the target subsystem, but also makes it easier for R&D personnel to solve the abnormal restart problem in a timely manner, and provides a foundation for reducing the probability of abnormal restart problems in the future.

[0019] In one possible implementation of the first aspect, where the target subsystem includes multiple processor cores, and the multiple processor cores include the target processor core, the process of the target subsystem executing the error handling flow of the root process domain may further include: the target subsystem shutting down other processor cores besides the target processor core. Here, the target processor core is the processor core executing the exception handling task, which is the task executed by the target subsystem after detecting an abnormal crash. Afterwards, the target subsystem obtains the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, and obtains the target fault event from the target information.

[0020] In this embodiment, the target subsystem can shut down other hardware threads within the target subsystem to ensure that tasks executed by other hardware threads cease processing. This ensures that all processor cores in the target subsystem, except for the target processor core, stop working, leaving only the target processor core to execute the aforementioned exception handling tasks. This reduces the likelihood of exception handling tasks being affected by other tasks, improving the efficiency of information generation (i.e., fault information and call stack information).

[0021] In one possible implementation of the first aspect, the process by which the target subsystem generates fault information and call stack information may further include: if the abnormal process ID is different from the target process ID, the target subsystem may execute a user process domain error handling procedure. The user process domain error handling procedure is used to generate fault information and call stack information, and to enable the application processor to receive the fault information and call stack information sent by the target subsystem.

[0022] In this embodiment, if the abnormal process ID in the target register information is different from the target process ID, it indicates that the abnormal process ID belongs to the user process PD, meaning that the fault belongs to a process failure in the ADSP subsystem. Therefore, the ADSP subsystem can execute the error handling process of the user process domain. This ensures the efficiency of obtaining fault information and call stack information, providing convenient conditions for accelerating the subsequent troubleshooting of restart problems.

[0023] In one possible implementation of the first aspect, the process by which the target subsystem executes the user process domain error handling flow may specifically include: the target subsystem obtaining the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, and obtaining the target fault event from the target information. Then, the target subsystem may perform a call stack backtracking operation and generate call stack information. Afterwards, the target subsystem may determine whether the process domain restart function is enabled. If the process domain restart function is enabled, the target subsystem may send fault information and call stack information to the application processor through the communication interface.

[0024] In this embodiment, if the process domain restart function is enabled, it means that the target subsystem can restart only at the process domain level. The target subsystem can execute the process restart process, which involves sending fault information and call stack information to the application processor through the communication interface. This improves the efficiency of obtaining fault information and call stack information, providing convenient conditions for accelerating the subsequent troubleshooting of restart problems.

[0025] In one possible implementation of the first aspect, the process by which the target subsystem obtains fault information may specifically include: the target subsystem determining whether the target process list includes the target process corresponding to the abnormal process ID. The target process list includes at least one registered process, which includes the process ID and / or process name. Then, if the target process list includes the target process corresponding to the abnormal process ID, the target subsystem obtains the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, and obtains the target fault event from the target information.

[0026] In this embodiment, if the target process list includes the target process corresponding to the abnormal process ID, it indicates that the target process is a pre-registered process. Therefore, the target subsystem can further determine the fault information and call stack information. This reduces unnecessary resource waste caused by the target process being a temporary process, thereby improving the utilization rate of computing resources.

[0027] In one possible implementation of the first aspect, the process of the target subsystem executing the user process domain error handling procedure may further include: if the process domain restart function is not enabled, the target subsystem can save the fault information and call stack information to shared memory. Then, the target subsystem can send a target interrupt signal to the application processor. Subsequently, upon receiving the target interrupt signal from the target subsystem, the application processor retrieves the fault information and call stack information from the shared memory.

[0028] In this embodiment, if the process domain restart function is not enabled, it means that the target subsystem cannot restart at the process domain level. The target subsystem can execute the subsystem recovery process, which involves saving the fault information and call stack information to shared memory and sending a target interrupt signal to the application processor. This not only improves the convenience of information retrieval but also reduces the possibility of call stack information loss due to a complete target subsystem restart, thus increasing the storage capacity of call stack information and providing convenient conditions for accelerating subsequent troubleshooting of restart issues.

[0029] In one possible implementation of the first aspect, the process of the target subsystem executing the user process domain error handling procedure may further include: if the exception process ID and the target process ID are different, the target subsystem can save the target register information to a global queue. Then, the target subsystem can wake up the user process domain error handling task. After the user process domain error handling task is woken up, the target subsystem can retrieve the target register information from the global queue and execute the user process domain error handling procedure.

[0030] In one possible implementation of the first aspect, the process by which the target subsystem generates call stack information may specifically include: the target subsystem obtaining a target stack frame pointer from target register information. Then, if the target stack frame pointer is not empty and the target count is less than or equal to a first preset value, the target subsystem determines the return address of the first instruction based on the stack frame pointer address of the first instruction included in the target stack frame pointer. Here, the target count is the number of times the target subsystem calculates the return address. The first instruction is the instruction that calls the instruction corresponding to the target stack frame pointer. Then, if the return address of the first instruction is the same as the return address of the second instruction, the target subsystem determines the return address of the second instruction as the return address of the historical instruction. Here, the second instruction is the instruction executed before the first instruction and is a higher-level instruction that has a calling relationship with the first instruction.

[0031] In this embodiment, if the return address of the first instruction is the same as the return address of the second instruction, it indicates that the target subsystem may have already calculated all stack frame pointers included in the call stack. Therefore, to reduce the occurrence of the target subsystem repeatedly calculating the return address of the same instruction, the target subsystem can directly determine the return address of the second instruction as the return address of the historical instruction. In this way, unnecessary resource waste can be reduced and the utilization rate of computing resources can be improved.

[0032] In one possible implementation of the first aspect, the process of the target subsystem generating call stack information may further include: if the return address of the first instruction is different from the return address of the second instruction, the target subsystem can determine the stack frame pointer of the first instruction based on the target stack frame pointer. Then, the target subsystem can increment the target count value by 1 to obtain a new target count value. Afterwards, the target subsystem can repeatedly execute the process, using the stack frame pointer of the first instruction as the new target stack frame pointer.

[0033] In this embodiment, if the return address of the first instruction is different from the return address of the second instruction, it indicates that the target subsystem has not completed the calculation of all stack frame pointers included in the call stack. Therefore, the target subsystem can use the stack frame pointer of the first instruction as the new target stack frame pointer and return to execute the step of "the target subsystem determining whether the target stack frame pointer is null". In this way, the integrity of the return address acquisition of historical instructions can be ensured, providing convenient conditions for accurate location of the restart reason in the future.

[0034] In one possible implementation of the first aspect, the process of the target subsystem generating call stack information may further include: when the target stack frame pointer is null, the target subsystem determines the return address of the second instruction as the return address of the historical instruction.

[0035] In this embodiment, if the target stack frame pointer is null, it means that the target stack frame pointer does not include the stack frame pointer address of the previous instruction. Therefore, the target subsystem can directly determine the return address of the second instruction as the return address of the historical instruction. This reduces unnecessary resource waste and improves the utilization rate of computing resources.

[0036] In one possible implementation of the first aspect, the process of the target subsystem generating call stack information may further include: if the target count value is greater than a first preset value, the target subsystem determines the return address of the second instruction as the return address of the historical instruction.

[0037] In this embodiment, if the target count value is greater than a first preset value, it indicates that the return addresses of all stack frame pointers in the call stack have been calculated. Therefore, the target subsystem can directly determine the return address of the second instruction as the return address of the historical instruction. This reduces unnecessary resource waste and improves the utilization rate of computing resources.

[0038] In one possible implementation of the first aspect, when the return address of the first instruction is the same as the return address of the second instruction, the process by which the target subsystem determines the return address of the historical instruction may specifically include: if the target count value is greater than a second preset value, and if the return address of the first instruction is the same as the return addresses of all second instructions of a second preset number, the target subsystem may determine the return address of the second instruction as the return address of the historical instruction. Here, the second preset value is less than the first preset value. The target second instruction is the second instruction with the closest calling relationship to the first instruction.

[0039] In some embodiments, if the target count value is greater than a second preset value, it indicates that the target subsystem has a high probability of having completed the calculation of all stack frame pointers included in the call stack. Therefore, to reduce the occurrence of the target subsystem repeatedly calculating the return address of the same instruction, the target subsystem can determine the return address of the second instruction as the return address of the historical instruction. This can improve the utilization of computing resources.

[0040] In one possible implementation of the first aspect, the method further includes: if the target count value is less than or equal to a second preset value, or if the return address of the first instruction is different from the return address of a second preset number of target second instructions, the target subsystem can determine the stack frame pointer of the first instruction based on the target stack frame pointer. Then, the target subsystem can increment the target count value by 1 to obtain a new target count value. Afterwards, the target subsystem can repeatedly execute the first instruction's stack frame pointer as the target stack frame pointer.

[0041] In some embodiments, if the target count value is less than or equal to a second preset value, or if the return address of the first instruction is different from the return address of the second preset number of target second instructions, it indicates that some stack frame pointers in the call stack have not been fully calculated. Therefore, the target subsystem can use the stack frame pointer of the first instruction as the new target stack frame pointer and return to execute the step of "the target subsystem determining whether the target stack frame pointer is empty". This ensures the completeness of the return address acquisition for historical instructions, providing convenient conditions for accurate location of the restart cause in the future.

[0042] Secondly, this application provides an exception handling system, which includes an electronic device and a server. The electronic device is used to execute the method described above.

[0043] Thirdly, this application provides an electronic device, which includes a memory and one or more processors; the memory and processors are coupled; the processors run a target subsystem, and the memory is used to store computer program code, which includes computer instructions; when the processor executes the computer instructions, the electronic device performs the method described above.

[0044] Fourthly, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described above.

[0045] Fifthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method described above.

[0046] In a sixth aspect, a chip is provided, comprising: an input interface, an output interface, a processor, and a memory, wherein the input interface, the output interface, the processor, and the memory are connected via an internal connection path, and the processor is used to execute code in the memory, wherein when the code is executed, the processor is used to execute the method described above.

[0047] The beneficial effects that the exception handling system described in the second aspect, the electronic device described in the third aspect, the computer-readable storage medium described in the fourth aspect, the computer program product described in the fifth aspect, and the chip described in the sixth aspect can achieve can be referred to the beneficial effects of the first aspect and any of its possible design embodiments, and will not be repeated here. Attached Figure Description

[0048] Figure 1 A schematic diagram illustrating the process of a target subsystem performing an exception handling task, provided for related technologies;

[0049] Figure 2 A schematic diagram illustrating the error handling process of a target subsystem executing the root process domain, provided for related technologies;

[0050] Figure 3 A schematic diagram illustrating the process of a target subsystem executing an error handling flow in a user process domain, provided for related technologies;

[0051] Figure 4 A hardware structure diagram of an electronic device provided in an embodiment of this application;

[0052] Figure 5 This is a schematic diagram of the structure of a processor in an electronic device provided in an embodiment of this application;

[0053] Figure 6A flowchart illustrating an exception handling method provided in an embodiment of this application;

[0054] Figure 7 A schematic diagram illustrating an exception handling process provided in an embodiment of this application;

[0055] Figure 8 This application provides a schematic diagram illustrating the error handling process of an ADSP subsystem executing the root process domain in an embodiment of the present application.

[0056] Figure 9 This application provides a schematic diagram illustrating the process of an ADSP subsystem executing an error handling flow in a user process domain, as illustrated in an embodiment of the present application.

[0057] Figure 10 A flowchart illustrating a method for performing a call stack backtracking operation in an ADSP subsystem, as provided in this application embodiment;

[0058] Figure 11 This is a schematic diagram of a call stack structure provided in an embodiment of this application. Detailed Implementation

[0059] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0060] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0061] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0062] In some embodiments, during the operation of an electronic device (such as a mobile phone), the target subsystem within the device may experience an anomaly such as a crash, leading to an automatic restart of the target subsystem. This crash is caused by a malfunction in the target subsystem. This not only affects the stability of the target subsystem but also impacts user efficiency and ultimately, the user experience.

[0063] The failure of the target subsystem can be a failure of the entire target subsystem or a failure of a process within the target subsystem. This target subsystem is equivalent to the subsystem running on the target processor, and it includes a user process domain (user pd) and a root process domain (root pd). For example, if the target processor is an audio digital signal processor (ADSP), the target subsystem can be an ADSP subsystem. Another example is a modem; the target subsystem can be a modem subsystem. Yet another example is a converter digital signal processor (CDSP); the target subsystem can be a CDSP subsystem.

[0064] Therefore, in order to accurately pinpoint the cause of the restart and resolve the issue promptly, thus laying the foundation for reducing the probability of future restarts, electronic devices in the testing phase can obtain a corresponding memory dump file after detecting an abnormal crash in the target subsystem. This dump file allows for the identification of the cause of the abnormal crash, i.e., the reason for the restart. The dump file can include all memory data from the time of the abnormal crash.

[0065] It is understandable that, since the aforementioned dump file includes all memory data at the time of the target subsystem's abnormal crash, and this memory data may contain information related to user privacy, if commercially available electronic devices obtain this dump file and report it to a server, there is a risk of user privacy being leaked, thereby affecting the user experience.

[0066] Therefore, to protect user security and privacy, the target subsystem does not generate a dump file; it only generates corresponding fault information when an abnormal crash occurs. This fault information may include at least one of the following: the target task name, the location information of the target fault instruction, the return address of the target fault instruction, and the cause of the target fault. The target task name refers to the name of the task executed when the target subsystem malfunctions. The target fault instruction refers to the instruction executed when the target subsystem malfunctions. The location information of the target fault instruction represents the line of code corresponding to the instruction within the program running the target task. This location information can be represented by the program counter (PC) address. The return address of the target fault instruction can be obtained from the link register (LR). The link register stores the return address of instructions (or functions). The cause of the target fault can be called the target fault event, which represents the abnormal situation caused by the abnormal crash of the target subsystem. For example, the target fault event may include memory allocation failure, thread creation failure, or audio service playback stream interruption.

[0067] For example, such as Figure 1As shown, the process by which the target subsystem generates fault information can specifically include: upon detecting an abnormal crash, the target subsystem can execute an exception handling task. This exception handling task can be the `err_ex_pd_1` task. It can be understood that upon detecting an abnormal crash, the target subsystem jumps to the abnormal interrupt handling flow to trigger the execution of this exception handling task. Afterwards, the target subsystem can obtain target register information. This target register information can include the abnormal process ID (identification). Then, the target subsystem can determine whether the abnormal process ID in the target register information is the same as the target process ID. If the abnormal process ID in the target register information is the same as the target process ID, the target subsystem can execute the error handling flow of the root process ID (PD). If the abnormal process ID in the target register information is different from the target process ID, the target subsystem can save the target register information to a global queue and wake up the error handling task of the user process ID (PSD). Afterwards, the target subsystem can execute the error handling flow of the user process ID (PSD). The error handling task of the user process ID (PSD) can be the `err_qdi_internal` task.

[0068] In one implementation, such as Figure 2 As shown, the error handling process of the target subsystem executing the root pd can specifically include: the target subsystem can shut down all processor cores except the target processor core. Then, the target subsystem can obtain the cause of the target failure from the fatal information and obtain the target task name, the location information of the target failure instruction, and the return address of the target failure instruction from the target register information. Next, the target subsystem can save the failure information to shared memory. This failure information may include the target task name, the location information of the target failure instruction, the return address of the target failure instruction, and the cause of the target failure. Then, the target subsystem can send a target interrupt signal to the application processor in the electronic device to notify the application processor that the entire target subsystem needs to be restarted. This target interrupt signal can be an SMP2P interrupt signal. After receiving the target interrupt signal from the target subsystem, the application processor retrieves the failure information from shared memory. Finally, the application processor can send the failure information to the server so that developers can locate the cause of the abnormal crash of the target subsystem based on this failure information.

[0069] In one implementation, such as Figure 3As shown, the error handling process of the aforementioned user PD can specifically include: The target subsystem can obtain target register information from the global queue. Then, the target subsystem can obtain the abnormal process ID from the target register information. Next, the target subsystem can determine whether the target process list includes the target process corresponding to the abnormal process ID. If the target process list includes the target process corresponding to the abnormal process ID, the target subsystem can obtain the cause of the target failure from the fatal information and obtain the target task name, the location information of the target failure instruction, and the return address of the target failure instruction from the target register information. Next, the target subsystem can determine whether the process domain restart function is enabled. If the process domain restart function is enabled, the target subsystem can send fault information to the application processor through the communication interface. Finally, upon receiving the fault information sent by the target subsystem, the application processor sends fault information to the server so that developers can locate the cause of the abnormal crash of the target subsystem based on the fault information.

[0070] Furthermore, if the aforementioned process domain restart function is not enabled, the target subsystem can save the fault information to shared memory. Then, the target subsystem can send a target interrupt signal to the application processor to notify it that the entire target subsystem needs to be restarted. Upon receiving the target interrupt signal from the target subsystem, the application processor retrieves the fault information from shared memory. The application processor can then send the fault information to the server, thereby pinpointing the cause of the abnormal crash in the target subsystem.

[0071] However, relying solely on the aforementioned fault information—that is, the information automatically generated when the target subsystem experiences an abnormal crash—may not accurately pinpoint the cause of the restart, thus hindering a quick resolution of the restart issue. Therefore, to improve the accuracy of restart cause identification, this application provides an exception handling method. In this method, upon detecting an abnormal crash in the target subsystem, the electronic device can acquire fault information and call stack information. The fault information represents the instruction information at the time of the abnormal crash in the target subsystem. The call stack information represents the hierarchical call relationship between the target fault instruction and at least one historical fault instruction. The fault information and call stack information are used to locate the cause of the abnormal crash in the target subsystem. Afterward, the target subsystem in the electronic device can perform a restart operation.

[0072] The aforementioned fault information may include at least one of the following: target task name, target fault cause, location information of the target fault instruction, and return address of the target fault instruction. The target task name is the name of the task executed when the target subsystem experiences an abnormal crash. The target fault cause characterizes the abnormal situation caused by the abnormal crash of the target subsystem. The return address of the target fault instruction is the address invoked when the target fault instruction is executed.

[0073] In this embodiment, after detecting an abnormal crash in the target subsystem, the electronic device not only obtains fault information but also call stack information. This allows researchers to determine the call relationship between the target fault instruction and historical instructions by combining the call stack information. Based on this call relationship, the root cause of the abnormal crash in the target subsystem can be determined, which means that the cause of the restart is accurately located. This not only improves the convergence efficiency of the abnormal restart problem of the target subsystem but also makes it easier for researchers to solve the abnormal restart problem in a timely manner, providing a foundation for reducing the probability of abnormal restart problems in the future.

[0074] In some examples, the electronic device in this application embodiment may be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as cellular phone, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device, media player, wearable device, and other devices with processing units. This application embodiment does not impose any special restrictions on the specific form of the electronic device.

[0075] For example, Figure 4 A schematic diagram of the hardware structure of electronic device 200 is shown. (For example...) Figure 4 As shown, the electronic device 200 may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 211, a power management module 212, a battery 213, an antenna 1, an antenna 2, a mobile communication module 240, a wireless communication module 250, an audio module 270, a sensor module 280, buttons 290, a motor 291, an indicator 292, cameras 1-N 293, a display screen 294, and a subscriber identification module (SIM) card interface 1-N 295, etc.

[0076] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 200. In other embodiments of this application, the electronic device 200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0077] Processor 210 may include one or more processing units, such as: application processor (AP), audio digital signal processor (ADSP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. The different processing units may be independent devices or integrated into one or more processors.

[0078] In some embodiments of this application, the processor 210 may include an access point (AP) and an active digital signal processing unit (ADSP). The AP may run a first operating system. For example, the first operating system may be... Operating System. The ADSP subsystem running on the ADSP handles tasks related to power, audio, and sensors. For example, the ADSP subsystem can handle tasks related to speech recognition and voice commands. Exemplarily, the ADSP subsystem can run a second operating system. For example, the second operating system can be a real-time operating system (Qurt OS). That is, the operating system running on the AP is different from the operating system running on the ADSP.

[0079] It is understandable that since the AP processor and the ADSP processor are independent processing units, the AP processor will not be affected if the ADSP subsystem running by the ADSP processor crashes abnormally. In other words, the AP processor will not perform a restart operation; the AP processor will only report the received fault information and call stack information to the server.

[0080] In some cases, such as Figure 5As shown, taking processor 210 as an example, which includes an application processor and an ADSP subsystem, the application processor may include service programs and / or drivers. The service program may be a pd-mapper service program, used to receive fault information and call stack information sent by the ADSP subsystem through a communication interface when the ADSP subsystem's processes need to be restarted. For example, the communication interface may be a Qualcomm messaging interface (QMI). The service program can also be used to store configuration information for all process domains in the ADSP subsystem. The driver may be a QCOM Q6V5 driver program, used to receive a target interrupt signal sent by the ADSP subsystem when the entire ADSP subsystem needs to be restarted, and to retrieve fault information and call stack information from shared memory. For example, the target interrupt signal may be an SMP2P interrupt signal, used to notify the application processor that the entire ADSP subsystem needs to be restarted. Shared memory (SMEM) is a portion of the double data rate (DDR) memory in internal memory 221.

[0081] The aforementioned ADSP subsystem may include an exception handler (i.e., an err exception handler). This exception handler runs after an abnormal crash of the ADSP subsystem. It can be used to save target register information when the ADSP subsystem crashes. This target register information may include the stack frame pointer (FP) address at the time of the ADSP subsystem crash, the location information of the target fault instruction (i.e., PC address), the return address of the target fault instruction (i.e., LR address), and the stack address. The exception handler can also be used to generate a corresponding core dump file based on the target register information. The core dump file may include the target task name, the location information of the target fault instruction, and the target fault event. For example, the core dump file may be obtained from DDR memory. The exception handler may include error handling procedures in the user process domain and / or the root process domain.

[0082] In some embodiments, when running the error handling process of the user process domain described above, the ADSP subsystem can send fault information to the application processor through a communication interface. This fault information may include at least one of the following: target task name, location information of the target fault instruction, return address of the target fault instruction, and target fault event. Furthermore, the ADSP subsystem can also generate call stack information through call stack backtracking and send this call stack information to the application processor. When running the error handling process of the root process domain described above, the ADSP subsystem can store fault information in shared memory. Furthermore, the ADSP subsystem can also generate call stack information through call stack backtracking and store this call stack information in shared memory through a communication interface.

[0083] In one implementation, upon detecting an abnormal crash in the ADSP subsystem's process, the ADSP subsystem can run an exception handler to save target register information and generate a kernel dump file. Furthermore, the ADSP subsystem can invoke the user process domain error handling procedure through a callback function of the user process descriptor (user pd) to execute that procedure. Specifically, the ADSP subsystem can generate call stack information through call stack backtracking. Then, the ADSP subsystem can send the call stack information and fault information to the application processor via the QMI interface. Upon receiving the call stack information and fault information from the ADSP subsystem, the application processor can execute a process domain restart procedure and run a service routine to send the call stack information and fault information to the server. This process domain restart (PDR) procedure is used to trigger a restart of the ADSP subsystem's process.

[0084] In the event of an abnormal crash in the entire ADSP subsystem, the ADSP subsystem can execute the error handling process in the root process domain. Specifically, the ADSP subsystem can generate call stack information by backtracking the call stack. Then, the ADSP subsystem can save the call stack information and fault information to shared memory. Simultaneously, the ADSP subsystem can send a target interrupt signal to the application processor. This target interrupt signal indicates that the entire ADSP subsystem needs to be restarted. Upon receiving the target interrupt signal from the ADSP subsystem, the application processor can execute the subsystem recovery process and run the driver to trigger the interrupt callback function, retrieving the call stack information and fault information from shared memory. The subsystem recovery (SSR) process triggers the restart of the entire ADSP subsystem. The interrupt callback function can be a fatal interrupt function, a wdog interrupt function, etc. Finally, the application processor can send the call stack information and fault information to the server.

[0085] The processor 210 may also include a memory for storing instructions and data, thereby reducing the number of accesses to the internal memory 221 and improving program execution speed. In some embodiments, the memory in the processor 210 is a cache memory. This memory can store instructions or data that the processor 210 has just used or that are used repeatedly. If the processor 210 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 210, and thus improves system efficiency.

[0086] The wireless communication function of electronic device 200 can be implemented through antenna 1, antenna 2, mobile communication module 240, wireless communication module 250, modem processor, and baseband processor. Mobile communication module 240 can provide wireless communication solutions for electronic device 200, including 2G / 3G / 4G / 5G. Wireless communication module 250 can provide wireless communication solutions for electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies.

[0087] Electronic device 200 implements display functions through a GPU, a display screen 294, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 210 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0088] The display screen (or screen) 294 is used to display images, videos, etc. In some embodiments, the electronic device 200 may include one or N display screens 294, where N is a positive integer greater than 1. The display screen 294 may be a touchscreen.

[0089] Electronic device 200 can perform shooting functions through ISP, camera 293, video codec, GPU, display screen 294 and application processor.

[0090] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 200 selects a frequency, the DSP is used to perform Fourier transforms on the frequency energy.

[0091] The external storage interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 200. The external memory card communicates with the processor 210 through the external storage interface 220 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0092] Internal memory 221 can be used to store computer executable program code, which includes instructions. Processor 210 executes various functional applications and data processing of electronic device 200 by running the instructions stored in internal memory 221. Internal memory 221 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 200 (such as audio data, phonebook, etc.).

[0093] In addition, the internal memory 221 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0094] In some embodiments of this application, the internal memory 221 may include a DDR memory. The DDR memory can be used to store data, status, and other information currently being executed by the code program.

[0095] In some cases, the aforementioned DDR memory may include shared memory. This shared memory is used to store fault information and call stack information in the event of an abnormal crash in the entire target subsystem, allowing the application processor to retrieve this information from the shared memory. It can be understood that this shared memory enables the application processor and the target subsystem to achieve fast and efficient information exchange, thereby resolving inter-processor communication problems (such as data exchange file issues).

[0096] Electronic device 200 can implement audio functions through audio module 270 and application processor, such as music playback and recording. The audio module 270 may include a speaker, receiver, microphone, and headphone jack.

[0097] Buttons 290 include a power button, volume buttons, etc. Indicator 292 may be an indicator light.

[0098] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a limitation on the structure of the electronic device. In other embodiments, the electronic device may include more or fewer modules than those provided in the above embodiments, and the modules may employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments. The hardware structure of the electronic device provided in this application embodiment can also be found in... Figure 4 The hardware structure of the electronic device 200 shown is illustrated. The methods in the following embodiments can all be implemented in an electronic device possessing the above-described hardware structure.

[0099] Based on the electronic device described above, this application provides an exception handling method. In this method, when an abnormal crash of a target subsystem is detected, the electronic device can obtain fault information and call stack information from the target subsystem. Then, the target subsystem in the electronic device can be restarted and send the fault information and call stack information to the server, so as to analyze the root cause of the abnormal crash of the target subsystem based on the fault information and call stack information.

[0100] The following example uses a mobile phone as the electronic device and an ADSP subsystem as the target subsystem to illustrate the exception handling method provided in this application. Specifically, as shown below... Figure 6 As shown, the exception handling method may include S301 to S304:

[0101] S301, the phone detected an abnormal crash in the ADSP subsystem.

[0102] In some cases, the mobile phone can monitor the processing flow of the ADSP subsystem in real time during operation, allowing it to promptly detect any abnormal crashes of the ADSP subsystem. For example, if any instruction within a program executed by the ADSP subsystem malfunctions, it indicates a failure in the ADSP subsystem, meaning the mobile phone can detect an abnormal crash. For instance, taking instruction A as an example, if the ADSP subsystem cannot call address A while running the program, it indicates an abnormal instruction within the program. Therefore, the mobile phone can detect an abnormal crash of the ADSP subsystem.

[0103] S302, the mobile phone obtains fault information and call stack information from the ADSP subsystem. The call stack information is used to characterize the hierarchical call relationship between the target fault instruction and at least one historical instruction.

[0104] Specifically, after detecting an abnormal crash in the ADSP subsystem, the mobile phone can obtain fault information and call stack information from the ADSP subsystem. The fault information represents the instruction information at the time of the abnormal crash in the ADSP subsystem. The call stack information represents the hierarchical call relationship between the target faulty instruction and at least one historical instruction.

[0105] In some cases, the aforementioned fault information may include at least one of the following: target task name, location information of the target fault instruction, return address of the target fault instruction, and target fault event. The target task name refers to the name of the task executed when the ADSP subsystem experiences an abnormal crash. The target fault instruction refers to the instruction executed when the ADSP subsystem experiences an abnormal crash. The location information of the target fault instruction is used to characterize the line of code corresponding to the target fault instruction in the program running the target task. This location information is equivalent to the stack frame pointer address, which can be represented by the PC address. The return address of the target fault instruction is the address called when the target fault instruction is executed. This return address can be obtained from the link register, which stores the return address of the instruction. The target fault event characterizes the abnormal situation caused by the abnormal crash of the ADSP subsystem. For example, the target fault event may include memory allocation failure, thread creation failure, audio service playback stream interruption, etc.

[0106] In some embodiments, the call stack information described above may include the return address of at least one historical instruction. This return address of the historical instruction is used to characterize the call relationship between the historical instruction and the target fault instruction. For example, taking the target fault instruction as a third-level instruction, the historical instructions may include second-level instructions preceding the third-level instructions, and first-level instructions preceding the second-level instructions.

[0107] S303, the mobile phone sends fault information and call stack information to the server.

[0108] Specifically, after obtaining the aforementioned fault information and call stack information, the mobile phone can send the fault information and call stack information to the server so that the server can store the fault information and call stack information.

[0109] The aforementioned server can be a single server, a server cluster, a distributed server, a centralized server, a cloud server, or even a computer, etc., with no specific limitations. For example, the server can also be a big data website.

[0110] In one implementation, upon receiving fault information and call stack information from the mobile phone, the server can store the fault information and call stack information. This allows developers to easily determine the call relationship between the target faulty instruction and historical instructions by combining the call stack information. Based on this call relationship, they can then determine the root cause of the ADSP subsystem's abnormal crash, achieving precise location of the restart cause. This not only improves the convergence efficiency of ADSP subsystem abnormal restart issues but also facilitates timely resolution of these issues by developers, laying the foundation for reducing the probability of subsequent abnormal restarts.

[0111] S304, the ADSP subsystem in the phone performs a reboot operation.

[0112] Specifically, after obtaining the aforementioned fault information and call stack information, the phone can trigger the ADSP subsystem to perform a restart operation, meaning the phone can restart the ADSP subsystem. This ensures the ADSP subsystem can operate normally, thereby improving the phone's operational stability.

[0113] In some embodiments, after the mobile phone obtains the aforementioned fault information and call stack information, the ADSP subsystem can automatically perform a restart operation without requiring the mobile phone to trigger the ADSP subsystem to perform a restart operation. This improves the restart efficiency of the ADSP subsystem.

[0114] It should be noted that the process of the mobile phone sending fault information and call stack information, as well as the process of the mobile phone triggering the ADSP subsystem to perform a restart operation, can be executed simultaneously or in a preset order, without any specific limitation.

[0115] For example, the phone can execute steps S303 and S304 simultaneously. Alternatively, the phone can execute step S303 first, then step S304. Yet another example: the phone can execute step S304 first, then step S303.

[0116] The above describes how a mobile phone obtains fault information and call stack information, enabling developers to pinpoint the root cause of an abnormal crash in the ADSP subsystem based on this information. The following will combine... Figure 5 The structure shown and Figure 7 The exception handling process shown details how the application processor in the mobile phone obtains fault information and call stack information.

[0117] S4001, the ADSP subsystem detected an abnormal crash.

[0118] S4002, the ADSP subsystem executes an exception handling task.

[0119] It is understandable that after detecting an abnormal crash due to a fault, the ADSP subsystem will jump to the abnormal interrupt handling flow to trigger the ADSP subsystem to execute the abnormal handling task. This abnormal handling task can be the err_ex_pd_1 task.

[0120] In one implementation, the ADSP subsystem can perform the above-mentioned exception handling task by calling the callback function of err_exception_handler().

[0121] S4003, the ADSP subsystem acquires target register information. This target register information includes the exception process ID.

[0122] Specifically, after executing the aforementioned exception handling task, the ADSP subsystem can obtain target register information. This target register information may include the exception process ID.

[0123] In some embodiments, the target register information may further include at least one of the target task name, the location information of the target fault instruction, and the return address of the target fault instruction.

[0124] S4004, the ADSP subsystem determines whether the abnormal process ID in the target register information is the same as the target process ID.

[0125] The target process ID mentioned above is the identifier of the process executing the exception handling task; in other words, the target process ID is used to identify the process currently running in the ADSP subsystem. It can be understood that since the exception handling task is executed by the root process controller (PD), if the target process ID is the same as the exception process ID in the target register information, it means that the exception process ID belongs to the root PD. Conversely, if the target process ID is different from the exception process ID in the target register information, it means that the exception process ID belongs to the user process controller (PD).

[0126] In some embodiments, the ADSP subsystem can determine whether the abnormal process ID in the target register information is the same as the target process ID. If the abnormal process ID in the target register information is the same as the target process ID, it indicates that the abnormal process ID belongs to the root process PD, meaning that the fault belongs to the entire ADSP subsystem. Therefore, the ADSP subsystem can execute step S4005 to execute the error handling procedure for the root process domain. If the abnormal process ID in the target register information is different from the target process ID, it indicates that the abnormal process ID belongs to the user process PD, meaning that the fault belongs to a process within the ADSP subsystem. Therefore, the ADSP subsystem can execute step S4011 to execute the error handling procedure for the user process domain.

[0127] S4005, if the abnormal process ID in the target register information is the same as the target process ID, the ADSP subsystem executes the error handling process of the root process domain.

[0128] Specifically, after confirming that the abnormal process ID in the target register information matches the target process ID, the ADSP subsystem can execute the root process domain error handling procedure. This root process domain error handling procedure can be used to save fault information and call stack information in shared memory and send a target interrupt signal to the application processor, enabling the application processor to retrieve the fault information and call stack information from shared memory. In other words, this root process domain error handling procedure is used to generate fault information and call stack information, and to enable the application processor to retrieve these information from shared memory. The target interrupt signal is an smp2p interrupt signal, which indicates that the entire ADSP subsystem needs to be restarted.

[0129] S4006, the application processor receives the target interrupt signal sent by the ADSP subsystem.

[0130] Specifically, after the error handling process in the root process domain is completed, the application processor can receive the target interrupt signal sent by the ADSP subsystem.

[0131] In S4007, the application processor obtains fault information and call stack information from shared memory through the driver.

[0132] Specifically, after receiving the target interrupt signal sent by the ADSP subsystem, the application processor can obtain fault information and call stack information from the aforementioned shared memory through the driver.

[0133] It should be noted that during the operation of the above driver, the application processor can obtain fault information and call stack information from shared memory and report the fault information and call stack information to the server so as to locate the cause of the abnormal crash of the ADSP subsystem based on the fault information and call stack information.

[0134] S4008, the application processor sends fault information and call stack information to the server.

[0135] Specifically, after obtaining the aforementioned fault information and call stack information, the application processor can send the aforementioned fault information and call stack information to the server so that the server can store the fault information and call stack information.

[0136] S4009: Upon receiving fault information and call stack information from the application processor, the server stores the fault information and call stack information.

[0137] Specifically, after receiving the fault information and call stack information sent by the mobile phone, the server can store the fault information and call stack information. This allows developers to easily determine the call relationship between the target faulty instruction and historical instructions by combining the call stack information. Based on this call relationship, they can then determine the root cause of the abnormal crash in the ADSP subsystem, achieving precise location of the restart cause. This not only improves the convergence efficiency of ADSP subsystem abnormal restart problems but also facilitates timely resolution of these problems by developers, laying the foundation for reducing the probability of abnormal restarts in the future.

[0138] S4010, restart the entire ADSP subsystem.

[0139] Specifically, after sending the aforementioned target interrupt signal to the application processor, the ADSP subsystem can execute the SSR processing flow to trigger a restart of the entire ADSP subsystem. This ensures the normal operation of the ADSP subsystem, thereby improving the phone's operational stability.

[0140] S4011, if the abnormal process ID in the target register information is different from the target process ID, the ADSP subsystem saves the target register information to the global queue.

[0141] Specifically, after determining that the abnormal process ID in the target register information is different from the target process ID, the ADSP subsystem can save the target register information to a global queue so that the subsequent error handling task (err_qdi_internal) of the user process can retrieve the target register information from the global queue. The global queue can be err_qdi_internal.queue. This ensures the independence of tasks within the ADSP subsystem, reduces competition between tasks caused by simultaneous processing, and improves the execution efficiency of the user process's error handling task.

[0142] In one implementation, the ADSP subsystem can save the aforementioned target register information to a global queue using q_put(&(err_qdi_internal.queue), &(data->node)).

[0143] S4012, the ADSP subsystem executes the error handling process of the user process domain.

[0144] Specifically, after the target register information is stored in the aforementioned global queue, the ADSP subsystem can execute the user process domain error handling procedure. This user process domain error handling procedure can be used to send fault information and call stack information to the application processor, so that the application processor can receive the fault information and call stack information.

[0145] In some embodiments, the ADSP subsystem may wake up the error handling task of the aforementioned user process so that the ADSP subsystem can execute the error handling process of the user process domain.

[0146] Specifically, the ADSP subsystem can trigger the user process's error handling task to perform error handling procedures in the user process domain by setting a wake-up signal. For example, the ADSP subsystem can set the wake-up signal using the `err_qdi_ctxt_invoke_sig` function.

[0147] S4013, the application processor receives an exception message sent by the ADSP subsystem.

[0148] Specifically, after the error handling process in the aforementioned user process domain has been completed, the ADSP subsystem can send an exception message to the application processor via the QMI interface, so that the application processor can obtain fault information and call stack information. The exception message can be a QMI message, which includes the aforementioned fault information and call stack information.

[0149] S4014, the application processor parses the exception message through the service program to obtain fault information and call stack information.

[0150] Specifically, after receiving an exception message from the ADSP subsystem, the application processor can parse the exception message to obtain fault information and call stack information.

[0151] It should be noted that during the operation of the above service program, the application processor can parse the exception message and report the parsed fault information and call stack information to the server, so as to locate the cause of the abnormal crash of the ADSP subsystem based on the fault information and call stack information.

[0152] S4015, the application processor sends fault information and call stack information to the server.

[0153] Specifically, after obtaining the aforementioned fault information and call stack information, the application processor can send the fault information and call stack information to the server so that the server can store the fault information and call stack information.

[0154] S4016: Upon receiving fault information and call stack information from the application processor, the server stores the fault information and call stack information.

[0155] Specifically, after receiving the fault information and call stack information sent by the mobile phone, the server can store the fault information and call stack information. This allows developers to easily determine the call relationship between the target faulty instruction and historical instructions by combining the call stack information. Based on this call relationship, they can then determine the root cause of the abnormal crash in the ADSP subsystem, achieving precise location of the restart cause. This not only improves the convergence efficiency of ADSP subsystem abnormal restart problems but also facilitates timely resolution of these problems by developers, laying the foundation for reducing the probability of abnormal restarts in the future.

[0156] S4017, restart the ADSP subsystem process.

[0157] Specifically, after sending the aforementioned exception message to the application processor, the ADSP subsystem can execute the PDR processing flow to trigger a restart of the ADSP subsystem's processes. This ensures the normal operation of the ADSP subsystem, thereby improving the phone's operational stability.

[0158] It should be noted that steps S4005 to S4010 above are the handling procedures for an abnormal crash of the entire subsystem (i.e., the ADSP subsystem), and steps S4011 to S4017 above are the handling procedures for an abnormal crash of a subsystem process. In other words, if the abnormal process ID in the target register information is the same as the target process ID, it indicates that this restart is caused by an abnormal crash of the entire ADSP subsystem. Therefore, the ADSP subsystem can execute steps S4005 to S4010. Conversely, if the abnormal process ID in the target register information is different from the target process ID, it indicates that this restart is caused by an abnormal crash of a process within the ADSP subsystem. Therefore, the ADSP subsystem can execute steps S4011 to S4017.

[0159] In one implementation, such as Figure 8 As shown, the process by which the ADSP subsystem executes the error handling flow of the root process domain can specifically include S501 to S505:

[0160] S501, the ADSP subsystem shuts down all processor cores except the target processor core.

[0161] Specifically, after confirming that the exception process ID in the target register information matches the target process ID, the ADSP subsystem can shut down other hardware threads within the ADSP subsystem. This ensures that tasks executed by other hardware threads cease processing, thereby ensuring that all processor cores in the ADSP subsystem, except the target processor core, stop working, leaving only the target processor core to execute the aforementioned exception handling task. This reduces the likelihood of exception handling tasks being affected by other tasks, improving the efficiency of information generation (i.e., fault information and call stack information).

[0162] In one implementation, the ADSP subsystem can use the err_enter_stm_mode function to shut down other hardware threads within the ADSP subsystem.

[0163] S502, the ADSP subsystem generates fault information and saves the fault information to shared memory.

[0164] In some embodiments, the ADSP subsystem can acquire fatal information (or target information). Fatal information refers to error information recorded by the ADSP subsystem when an abnormal crash occurs, which can lead to program exceptions. This fatal information may include target fault events. Target fault events characterize the abnormal situation caused by the abnormal crash of the ADSP subsystem. For example, the target fault event may include memory allocation failure, thread creation failure, audio service playback stream interruption, etc. Subsequently, the ADSP subsystem can save the target fault event from the fatal information, the target task name from the target register information, the location information of the target fault instruction, and the return address of the target fault instruction to the coredump information to generate the aforementioned fault information.

[0165] In some cases, after generating the aforementioned fault information, the ADSP subsystem can save this information to shared memory. This allows the application processor to retrieve the fault information from shared memory upon receiving a target interrupt signal. This not only improves the ease of information retrieval but also reduces the likelihood of fault information loss due to a complete ADSP subsystem restart, enhancing fault information storage capacity and providing a foundation for subsequent troubleshooting of restart issues by R&D personnel.

[0166] In one implementation, the ADSP subsystem can generate the aforementioned fault information through the err_log_ssr_failure_reason callback function and save the fault information to shared memory.

[0167] The S503 ADSP subsystem generates call stack information by backtracking the call stack.

[0168] Specifically, the ADSP subsystem can generate call stack information through call stack backtracking; that is, the ADSP subsystem can perform call stack backtracking operations to generate call stack information. The call stack backtracking process will be described in detail below.

[0169] S504, the ADSP subsystem saves the call stack information to shared memory.

[0170] Specifically, after generating the aforementioned call stack information, the ADSP subsystem can save the call stack information to shared memory. This allows the application processor to retrieve the call stack information from shared memory upon receiving a target interrupt signal. This not only improves the ease of information retrieval but also reduces the likelihood of call stack information loss due to a restart of the entire ADSP subsystem, enhancing the storage capacity of call stack information and providing convenience for developers to expedite troubleshooting restart issues.

[0171] In one implementation, the ADSP subsystem can generate the aforementioned call stack information through the err_log_ssr_call_stack callback function and save the call stack information to shared memory.

[0172] S505, the ADSP subsystem sends a target interrupt signal to the application processor. This target interrupt signal indicates that the entire ADSP subsystem needs to be restarted.

[0173] Specifically, after the shared memory stores the call stack information and fault information, the ADSP subsystem can send a target interrupt signal to the application processor to notify the application processor that the entire ADSP subsystem needs to be restarted. This target interrupt signal can be an smp2p interrupt signal.

[0174] In some cases, upon receiving a target interrupt signal from the ADSP subsystem, the application processor can run a driver to retrieve fault information and call stack information from shared memory and report these information to the server. This driver can be a QCOM Q6V5 driver program.

[0175] In some embodiments, the application processor can obtain fault information and call stack information from shared memory. The application processor can then send this fault information and call stack information to the server, allowing the server to store them. This enables developers to combine the call stack information to determine the call relationship between the target faulty instruction and historical instructions, and further, based on this call relationship, determine the root cause of the ADSP subsystem's abnormal crash. This achieves precise location of the restart cause, improving the convergence efficiency of ADSP subsystem abnormal restart issues and facilitating timely resolution of these problems, thus laying the foundation for reducing the probability of subsequent abnormal restarts.

[0176] In one implementation, such as Figure 9 As shown, the process by which the ADSP subsystem executes the error handling flow of the user process domain can specifically include S601 to S609:

[0177] S601, the ADSP subsystem obtains target register information from the global queue.

[0178] Specifically, after the error handling task (err_qdi_internal) of the aforementioned user process is awakened, the ADSP subsystem can obtain the target register information from the aforementioned global queue. In one implementation, the ADSP subsystem can obtain the target register information from the aforementioned global queue using q_get(&(err_qdi_internal.queue), &(data->node)).

[0179] In some embodiments, after obtaining the target register information, the ADSP subsystem may call the user process domain error handling function (err_qdi_process_pd_err) to trigger the ADSP subsystem to determine the fault information and call stack information, and send the fault information and call stack information to the application processor.

[0180] S602, the ADSP subsystem obtains the abnormal process number from the target register information.

[0181] Specifically, after obtaining the aforementioned target register information, the ADSP subsystem can retrieve the abnormal process ID from the target register information. In one implementation, the ADSP subsystem can use the `qurt_process_attr_get(pid,&p_attr)` function to retrieve the abnormal process ID from the target register information.

[0182] S603, the ADSP subsystem determines whether the target process list includes the target process corresponding to the abnormal process number.

[0183] Specifically, after obtaining the aforementioned abnormal process ID, the ADSP subsystem can acquire a target process list. This target process list includes multiple registered processes. The task type corresponding to each registered process can be an audio task, a charging task, a sensor task, etc. For example, this target process list can be of the err_qdi_internal.list class.

[0184] It should be noted that the above target process list is pre-configured during the ADSP subsystem initialization process. In other words, each process in this target process list is pre-registered, meaning it is a registered process.

[0185] In some embodiments, the ADSP subsystem can determine whether the target process list includes the target process corresponding to the abnormal process ID. If the target process list includes the target process corresponding to the abnormal process ID, it indicates that the target process is a pre-registered process. Therefore, the ADSP subsystem can execute step S604 to further determine the fault information and call stack information. If the target process list does not include the target process corresponding to the abnormal process ID, it indicates that the target process has not been pre-registered, meaning that the target process may be a temporary process. Therefore, the ADSP subsystem does not need to continue determining the fault information and call stack information, that is, it does not need to execute steps S604 to S609.

[0186] Specifically, the ADSP subsystem can obtain process information for each registered process from the aforementioned target process list. This process information may include the process ID, process name, stack pointer size, and stack space. Then, the ADSP subsystem can determine if the process name of the target process is the same as the process name of any registered process in the target process list. If the process name of the target process is the same as the process name of any registered process in the target process list, the ADSP subsystem can determine that the target process list includes the target process corresponding to the abnormal process ID. If the process name of the target process is different from the process name of any registered process in the target process list, the ADSP subsystem can determine that the target process list does not include the target process corresponding to the abnormal process ID.

[0187] In one implementation, the ADSP subsystem can obtain process information of registered processes from the aforementioned target process list using the err_qdi_internal.list.user_pd_data function.

[0188] The S604 ADSP subsystem generates fault information based on the target register information and fatal information.

[0189] Specifically, after determining that the target process list includes the target process corresponding to the abnormal process number, the ADSP subsystem can obtain the cause of the target failure from the above fatal information, and obtain the target task name, the location information of the target failure instruction, and the return address of the target failure instruction from the above target register information, thereby generating the above failure information.

[0190] The S605 ADSP subsystem generates call stack information by tracing back the call stack.

[0191] Specifically, after determining that the target process list includes the target process corresponding to the abnormal process ID, the ADSP subsystem can generate call stack information through call stack backtracking. In other words, the ADSP subsystem can perform a call stack backtracking operation to generate call stack information. The call stack backtracking process will be described in detail below.

[0192] S606, the ADSP subsystem determines whether the process domain restart function is enabled.

[0193] Specifically, after generating the aforementioned call stack information and fault information, the ADSP subsystem can determine whether the process domain restart function is enabled. This process domain restart function can be pre-configured during ADSP subsystem initialization. If the process domain restart function is enabled, it means the ADSP subsystem can restart only the process domain, and the ADSP subsystem can execute step S606, which means the ADSP subsystem can execute the process restart procedure. If the process domain restart function is not enabled, it means the ADSP subsystem cannot restart the process domain, and the ADSP subsystem can execute step S608, which means the ADSP subsystem needs to execute the subsystem recovery procedure.

[0194] With the process domain restart function enabled, the S607 ADSP subsystem sends fault information and call stack information to the application processor.

[0195] Specifically, after confirming that the aforementioned process domain restart function is enabled, the ADSP subsystem can directly send fault information and call stack information to the application processor, enabling the application processor to report this information to the server. This allows developers to easily determine the call relationship between the target faulty instruction and historical instructions by combining the call stack information. Based on this relationship, they can then determine the root cause of the ADSP subsystem's abnormal crash, achieving precise location of the restart cause. This not only improves the convergence efficiency of ADSP subsystem anomalies but also facilitates timely resolution of the restart cause by developers, laying the foundation for reducing the probability of future anomalies.

[0196] In some embodiments, the ADSP subsystem can send fault information and call stack information to the application processor via a communication interface. This communication interface can be a QMI interface.

[0197] In one implementation, upon receiving fault information and call stack information from the ADSP subsystem, the application processor can run a service program to report the fault information and call stack information to the server. This service program can be a pd-mapper service program.

[0198] S608, when the process domain restart function is not enabled, the ADSP subsystem executes the root process domain error handling process.

[0199] Specifically, after confirming that the aforementioned process domain restart function is not enabled, the ADSP subsystem can execute the root process domain error handling procedure. This means the ADSP subsystem can save the aforementioned fault information and call stack information to shared memory, so that the application processor can retrieve this information from shared memory upon receiving the target interrupt signal. This not only improves the convenience of information retrieval but also reduces the possibility of information loss due to a restart of the entire ADSP subsystem, enhancing the phone's information storage capacity and providing convenient conditions for subsequent R&D personnel to expedite the troubleshooting of restart issues.

[0200] S609, the application processor receives the target interrupt signal sent by the ADSP subsystem.

[0201] Specifically, after the shared memory stores the call stack information and fault information, the ADSP subsystem can send a target interrupt signal to the application processor to notify the application processor that the entire ADSP subsystem needs to be restarted. This target interrupt signal can be an smp2p interrupt signal, which indicates that the entire ADSP subsystem needs to be restarted.

[0202] In some cases, upon receiving a target interrupt signal from the ADSP subsystem, the application processor can run a driver to retrieve fault information and call stack information from shared memory and report these information to the server. This driver can be a QCOM Q6V5 driver program.

[0203] In some embodiments, the application processor can obtain fault information and call stack information from shared memory. The application processor can then send the fault information and call stack information to the server, allowing the server to store them. This enables developers to combine the call stack information to determine the call relationship between the target faulty instruction and historical instructions, and further, based on this relationship, determine the root cause of the ADSP subsystem's abnormal crash. This achieves precise location of the restart cause, improving the convergence efficiency of ADSP subsystem abnormal restart issues and facilitating timely resolution of these problems, thus laying the foundation for reducing the probability of future abnormal restarts.

[0204] In one implementation, such as Figure 10 As shown, the process by which the ADSP subsystem generates call stack information through call stack backtracking can specifically include S701 to S710:

[0205] S701, the ADSP subsystem obtains the target stack frame pointer from the target register information.

[0206] The aforementioned target stack frame pointer refers to the stack frame pointer corresponding to the faulty instruction executed when the ADSP subsystem experiences an abnormal crash. A stack frame pointer is a pointer used to locate and access the function's stack frame during a function (i.e., instruction) call. In other words, this stack frame pointer includes the address of the stack frame pointer of the instruction preceding the current instruction.

[0207] For example, such as Figure 11 As shown, the instruction call order is func1->func2->func3 as an example. Here, func3 is the target fault instruction mentioned above. func2 is the parent instruction preceding func3. func1 is the parent instruction preceding func2. That is, when the ADSP subsystem runs the program, it first executes the func1 instruction, then the func2 instruction, and finally the func3 instruction.

[0208] As can be seen, in the call stack structure, each instruction includes a stack frame pointer, a return address, and temporary variables (local data). The stack frame pointer can include the address of the stack frame pointer of the parent instruction. That is, through this stack frame pointer, the call stack can point to the stack frame pointer of the parent instruction. For example, taking the stack frame pointer of the `func3` instruction as an example, this `func3` instruction's stack frame pointer can include the address of the stack frame pointer of the `func2` instruction. In other words, through the stack frame pointer of the `func3` instruction, the call stack can point to the stack frame pointer of the `func2` instruction. Similarly, taking the stack frame pointer of the `func2` instruction as an example, this `func2` instruction's stack frame pointer can include the address of the stack frame pointer of the `func1` instruction. In other words, through the stack frame pointer of the `func2` instruction, the call stack can point to the stack frame pointer of the `func1` instruction.

[0209] S702, the ADSP subsystem determines whether the target stack frame pointer is empty.

[0210] Specifically, after obtaining the target stack frame pointer, the ADSP subsystem can determine whether the target stack frame pointer is null. If the target stack frame pointer is null, it means that the target stack frame pointer does not include the stack frame pointer address of the previous level instruction. Therefore, the ADSP subsystem can execute step S710 to directly generate the return address of the target fault instruction. If the target stack frame pointer is not null, it means that the target stack frame pointer includes the stack frame pointer address of the previous level instruction. Therefore, the ADSP subsystem can execute step S703 to further determine the return address of the previous level instruction, that is, to determine the return address of the first instruction.

[0211] S703, the ADSP subsystem determines whether the target count value is greater than the first preset value.

[0212] Specifically, after determining that the target stack frame pointer is not null, the ADSP subsystem can determine whether the target count value is greater than a first preset value. The target count value refers to the number of times the ADSP subsystem calculates the return address. The first preset value can be a maximum value of stack frame pointers that the call stack can include, pre-set by the ADSP subsystem. This first preset value can be represented by `max_stack_level`. For example, this first preset value can be 100, 70, etc., without specific limitations.

[0213] In some embodiments, if the target count value is greater than a first preset value, it indicates that the return addresses of all stack frame pointers in the call stack have been calculated. Therefore, the ADSP subsystem can execute step S710 to directly generate the return address of at least one second instruction. If the target count value is less than or equal to the first preset value, it indicates that the return addresses of some stack frame pointers in the call stack have not been calculated. Therefore, the ADSP subsystem can execute step S704 to further determine the return address of the first instruction.

[0214] S704, the ADSP subsystem determines the return address of the first instruction based on the stack frame pointer address of the first instruction included in the target stack frame pointer.

[0215] Specifically, after determining that the target count value is less than or equal to a first preset value, the ADSP subsystem can determine the return address of the first instruction based on the stack frame pointer address of the first instruction included in the target stack frame pointer. The first instruction is the instruction that calls the instruction corresponding to the target stack frame pointer.

[0216] In some embodiments, the ADSP subsystem can add a target byte to the stack frame pointer address of the first instruction to obtain the return address of the first instruction, i.e., call_stack_addr[cnt] = LR. The target byte represents the number of bytes corresponding to each address in the call stack. For example, the target byte can be 0x004.

[0217] For example, such as Figure 11 As shown, taking the target stack frame pointer as the stack frame pointer of func3, which includes 0x004, and the target byte as 0x004, as an example, since the stack frame pointer of func3 includes the stack frame pointer address of func2, that is, the stack frame pointer address of func2 is 0x004. Therefore, the ADSP subsystem can determine that the return address of func2 includes the instruction information located between 0x004 and 0x008, that is, the return address of the first instruction can include the instruction information located between 0x004 and 0x008.

[0218] In some cases, since the call stack backtracking is executed in the root process, and considering that user processes cannot directly obtain address information from the root process, if the process corresponding to the error handling flow is a user process, the ADSP subsystem, after determining the return address of the first instruction, can access the return address of that first instruction in the root process. This ensures that the user process can obtain the return address of the first instruction generated in the root process, providing a basis for subsequently generating call stack information. It can be understood that the root process is equivalent to a process in kernel mode, and the user process is equivalent to a process in user mode.

[0219] In one implementation, the ADSP subsystem can access the return address of the first instruction generated in the root process through the qurt_qdi_copy_from_user function.

[0220] In some embodiments, after obtaining the return address of the first instruction, the ADSP subsystem can directly determine whether the return address of the first instruction is the same as the return address of the second instruction. The second instruction is the instruction executed before the first instruction and is at the next higher level that has a calling relationship with the first instruction. If the return address of the first instruction is the same as the return address of the second instruction, it indicates that the ADSP subsystem may have already calculated all stack frame pointers included in the call stack. Therefore, to reduce the occurrence of the ADSP subsystem repeatedly calculating the return address of the same instruction, the ADSP subsystem can directly execute step S710 to generate at least one return address of the second instruction, thereby generating the return address of the historical instruction. If the return address of the first instruction is different from the return address of the second instruction, it indicates that the ADSP subsystem has not completed the calculation of all stack frame pointers included in the call stack. Therefore, the ADSP subsystem can execute step S707 to determine the next higher level stack frame pointer.

[0221] In other embodiments, after obtaining the return address of the first instruction, the ADSP subsystem can determine whether the return address of the first instruction is the same as the return address of a second preset number of target second instructions. The target second instruction is the second instruction whose calling relationship is closest to that of the first instruction. Specifically, the process by which the ADSP subsystem determines whether the return address of the first instruction is the same as the return address of the second preset number of target second instructions can be obtained through the following steps S705-S706.

[0222] S705, the ADSP subsystem determines whether the target count value is greater than the second preset value.

[0223] Specifically, after receiving the return address of the first instruction, the ADSP subsystem can determine whether the target count value is greater than a second preset value. The second preset value is less than the first preset value. This second preset value can be preset according to actual conditions. For example, the second preset value can be 2, 3, 5, etc., without specific limitations.

[0224] In some embodiments, if the target count value is greater than the second preset value, it indicates that the ADSP subsystem has a high probability of having completed the calculation of all stack frame pointers included in the call stack. Therefore, to reduce the occurrence of the ADSP subsystem repeatedly calculating the return address of the same instruction, the ADSP subsystem can execute step S706 to determine whether all stack frame pointers included in the call stack have been calculated. This can reduce unnecessary resource waste and improve the utilization rate of ADSP computing resources. If the target count value is less than or equal to the second preset value, it indicates that the probability of the ADSP subsystem being able to complete the calculation of all stack frame pointers included in the call stack is low. Therefore, the ADSP subsystem can directly execute step S707 to determine the upper-level stack frame pointer.

[0225] S706, the ADSP subsystem determines whether the return address of the first instruction is the same as the return address of the second instruction of a second preset number.

[0226] In some embodiments, after determining that the target counter is greater than a second preset value, the ADSP subsystem can determine whether the return address of the first instruction is the same as the return address of a second preset number of target second instructions. The target second instruction is the second instruction whose call relationship is closest to that of the first instruction. If the return address of the first instruction is the same as the return address of the second preset number of target second instructions, it indicates that all stack frame pointers included in the call stack have been calculated. Therefore, the ADSP subsystem can execute S710 to generate the return address of at least one second instruction. If the return address of the first instruction is not the same as the return address of the second preset number of target second instructions, it indicates that some stack frame pointers in the call stack have not been calculated. Therefore, the ADSP subsystem can execute S707 to continue calculating the return address of the first instruction.

[0227] In one implementation, taking the second preset quantity as 2 as an example, the process by which the ADSP subsystem determines whether the return address of the first instruction is the same as the return address of the second instruction of the second preset quantity located after the first instruction can be represented by call_stack_addr[cnt] == ​​call_stack_addr[cnt-1] && call_stack_addr[cnt] == ​​call_stack_addr[cnt-2].

[0228] S707, the ADSP subsystem determines the pointer of the previous stack frame located before the target stack frame pointer from the call stack based on the target stack frame pointer.

[0229] Specifically, after determining that the return address of the first instruction is different from the return address of the second preset number of target second instructions, the ADSP subsystem can determine the previous stack frame pointer located before the target stack frame pointer from the call stack based on the stack frame pointer address of the first instruction included in the target stack frame pointer, so as to further determine the return address of the historical instruction.

[0230] It is understandable that since the target stack frame pointer contains the address of the stack frame pointer of the first instruction, it can point to the stack frame pointer of the instruction at the next higher level. Therefore, based on the address of the stack frame pointer of the first instruction included in the target stack frame pointer, the ADSP subsystem can determine the stack frame pointer of the instruction at the next higher level from the call stack, that is, determine the stack frame pointer of the first instruction.

[0231] In some cases, since the call stack backtracking is executed in the root process, and considering that user processes cannot directly obtain address information from the root process, if the process corresponding to the error handling flow is a user process, the ADSP subsystem, after determining the stack frame pointer of the previous level before the target stack frame pointer, can access the stack frame pointer address of that previous level stack frame pointer in the root process. This ensures that the user process can obtain the stack frame pointer address generated in the root process, providing a basis for subsequent generation of call stack information. It can be understood that the root process is equivalent to a process in kernel mode, and the user process is equivalent to a process in user mode.

[0232] In one implementation, the ADSP subsystem can access the stack frame pointer address of the parent stack frame pointer generated in the root process through the qurt_qdi_copy_from_user function.

[0233] S708, the ADSP subsystem increments the target count value by 1 to obtain a new target count value.

[0234] Specifically, after determining the pointer of the previous stack frame before the target stack frame pointer, the ADSP subsystem can increment the target count value by 1 to obtain a new target count value.

[0235] In S709, the ADSP subsystem uses the pointer to the previous stack frame as the pointer to the target stack frame.

[0236] In some embodiments, after setting the previous stack frame pointer as the target stack frame pointer, the ADSP subsystem can return to the execution step S702 to continue calculating the return address of the first instruction.

[0237] S710, the ADSP subsystem generates the return address for at least one second instruction.

[0238] The return address of the second instruction mentioned above is the return address of the historical instruction.

[0239] In some embodiments, after determining that the target stack frame pointer is null, the ADSP subsystem can generate the return address of at least one second instruction. This reduces the likelihood of continuing to calculate the return address of the first instruction because the target stack frame pointer does not include the stack frame pointer address of the first instruction, thus reducing unnecessary resource waste and improving the utilization rate of the ADSP subsystem's computing resources.

[0240] In other embodiments, after determining that the target stack frame pointer is not null and the target count value is greater than a first preset value, the ADSP subsystem can generate the return address of at least one second instruction. This reduces the occurrence of situations where the ADSP subsystem continues to calculate the return address even after all stack frame pointers in the call stack have been calculated, thus reducing unnecessary resource waste and improving the utilization rate of the ADSP subsystem's computing resources.

[0241] In some other embodiments, after determining that the target stack frame pointer is not empty, the target count value is less than or equal to a first preset value, and the return address of the first instruction is the same as the return addresses of a second preset number of target second instructions, the ADSP subsystem can generate the return address of at least one second instruction. This reduces the occurrence of situations where the ADSP subsystem continues to calculate return addresses even after all stack frame pointers in the call stack have been calculated, reducing unnecessary resource waste and thus improving the utilization rate of the ADSP subsystem's computing resources.

[0242] This application also provides a computer-readable storage medium including computer instructions that, when executed on the electronic device, cause the electronic device to perform the various functions or steps described in the method embodiments.

[0243] This application also provides a computer program product, including a computer program that, when run on an electronic device, causes the electronic device to perform the various functions or steps described in the above method embodiments.

[0244] This application provides a chip for executing instructions. When the chip is running, it executes the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0245] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0246] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0247] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0248] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0249] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0250] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An exception handling method, characterized in that, The method is applied to an electronic device running a first operating system, the electronic device including a target subsystem running a second operating system, the method comprising: Upon detecting an abnormal crash in the target subsystem, the electronic device acquires fault information and call stack information; wherein, the fault information represents the instruction information at the time of the abnormal crash in the target subsystem, and the call stack information is used to represent the hierarchical call relationship between the target fault instruction and at least one historical instruction, the target fault instruction is the instruction executed when the target subsystem crashes, and the fault information and the call stack information are used to locate the cause of the abnormal crash in the target subsystem; The target subsystem in the electronic device is restarted.

2. The method according to claim 1, characterized in that, The method further includes: The electronic device sends the fault information and the call stack information to the server.

3. The method according to claim 1 or 2, characterized in that, The call stack information includes the return address of at least one historical instruction, and the return address of the historical instruction is used to characterize the call relationship between the historical instruction and the target fault instruction.

4. The method according to any one of claims 1-3, characterized in that, The electronic device further includes an application processor running the first operating system. In the event of an abnormal crash detected in the target subsystem, the electronic device acquires fault information and call stack information, including: After detecting an abnormal crash, the target subsystem generates the fault information and the call stack information. The target subsystem sends the fault information and the call stack information to the application processor.

5. The method according to any one of claims 1-4, characterized in that, The fault information includes at least one of the following: target task name, target fault event, location information of the target fault instruction, and return address of the target fault instruction; wherein, the target task name is the name of the task executed when the target subsystem experiences an abnormal crash, the target fault event is used to characterize the abnormal situation caused by the abnormal crash of the target subsystem, and the return address of the target fault instruction is the address called when the target fault instruction is executed.

6. The method according to claim 4 or 5, characterized in that, After detecting an abnormal crash, the target subsystem generates the fault information and the call stack information, including: After detecting an abnormal crash, the target subsystem acquires target register information, including the abnormal process ID. If the abnormal process ID is the same as the target process ID, the target subsystem executes the error handling process of the root process domain; wherein, the target process ID is used to identify the process that the target subsystem is running, and the error handling process of the root process domain is used to generate the fault information and the call stack information, and to enable the application processor to obtain the fault information and the call stack information from shared memory; If the abnormal process ID is different from the target process ID, the target subsystem executes a user process domain error handling procedure; wherein, the user process domain error handling procedure is used to generate the fault information and the call stack information, and to enable the application processor to receive the fault information and the call stack information sent by the target subsystem.

7. The method according to claim 6, characterized in that, The target register information also includes the target task name, the location information of the target fault instruction, and the return address of the target fault instruction; The target subsystem executes the error handling process of the root process domain, including: The target subsystem obtains the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, and obtains the target fault event from the target information; wherein, the target information is the error information recorded by the target subsystem when an abnormal crash occurs; The target subsystem performs a call stack backtracking operation and generates the call stack information; The target subsystem saves the fault information and the call stack information to shared memory; The target subsystem sends a target interrupt signal to the application processor; wherein the target interrupt signal indicates that the entire target subsystem needs to be restarted. Upon receiving the target interrupt signal sent by the target subsystem, the application processor retrieves the fault information and the call stack information from the shared memory.

8. The method according to claim 7, characterized in that, The target subsystem includes multiple processor cores, including a target processor core, which is a processor core that executes an exception handling task. The exception handling task is a task executed by the target subsystem after detecting an abnormal crash. Before the target subsystem obtains the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, the method further includes: The target subsystem disables all processor cores except the target processor core.

9. The method according to any one of claims 6-8, characterized in that, The target subsystem executes the error handling process of the user process domain, including: The target subsystem obtains the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, and obtains the target fault event from the target information; The target subsystem performs a call stack backtracking operation and generates the call stack information; With the process domain restart function enabled, the target subsystem sends the fault information and the call stack information to the application processor through the communication interface.

10. The method according to claim 9, characterized in that, The target subsystem executes the error handling process of the user process domain, and further includes: If the process domain restart function is not enabled, the target subsystem saves the fault information and the call stack information to shared memory; The target subsystem sends the target interrupt signal to the application processor; Upon receiving the target interrupt signal sent by the target subsystem, the application processor retrieves the fault information and the call stack information from the shared memory.

11. The method according to claim 9 or 10, characterized in that, The target subsystem obtains the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, and obtains the target fault event from the target information, including: If the target process list includes the target process corresponding to the abnormal process number, the target subsystem obtains the target task name, the location information of the target fault instruction, and the return address of the target fault instruction from the target register information, and obtains the target fault event from the target information; wherein, the target process list includes at least one registered process information, and the registered process information includes the process number and / or process name.

12. The method according to any one of claims 6-11, characterized in that, If the abnormal process ID is different from the target process ID, the target subsystem executes the error handling procedure of the user process domain, which further includes: If the abnormal process ID is different from the target process ID, the target subsystem saves the target register information to the global queue; The target subsystem wakes up the error handling task of the user process domain; After the error handling task in the user process domain is awakened, the target subsystem obtains the target register information from the global queue and executes the error handling process in the user process domain.

13. The method according to any one of claims 7-12, characterized in that, The target register information also includes a target stack frame pointer. The target subsystem performs a call stack backtracking operation and generates the call stack information, including: The target subsystem obtains the target stack frame pointer from the target register information; When the target stack frame pointer is not empty and the target count value is less than or equal to a first preset value, the target subsystem determines the return address of the first instruction based on the stack frame pointer address of the first instruction included in the target stack frame pointer; wherein, the target count value is the number of times the target subsystem calculates the return address, and the first instruction is the instruction that calls the instruction corresponding to the target stack frame pointer; If the return address of the first instruction is the same as the return address of the second instruction, the target subsystem determines the return address of the second instruction as the return address of the historical instruction; wherein, the second instruction is an instruction executed before the first instruction and has a calling relationship with the first instruction at the next higher level.

14. The method according to claim 13, characterized in that, The target subsystem performs a call stack backtracking operation and generates the call stack information, and also includes: If the return address of the first instruction is different from the return address of the second instruction, the target subsystem determines the stack frame pointer of the first instruction based on the target stack frame pointer. The target subsystem increments the target count value by 1 to obtain a new target count value. The target subsystem repeatedly executes the stack frame pointer of the first instruction as the new target stack frame pointer.

15. The method according to claim 13 or 14, characterized in that, The target subsystem performs a call stack backtracking operation and generates the call stack information, and also includes: If the target stack frame pointer is null, or if the target count value is greater than a first preset value, the target subsystem determines the return address of the second instruction as the return address of the historical instruction.

16. The method according to any one of claims 13-15, characterized in that, When the return address of the first instruction is the same as the return address of the second instruction, the target subsystem determines the return address of the second instruction as the return address of the historical instruction, including: If the target count value is greater than the second preset value, and the return address of the first instruction is the same as the return address of the second instruction of the second preset number, the target subsystem determines the return address of the second instruction as the return address of the historical instruction; wherein, the second preset value is less than the first preset value, and the target second instruction is the second instruction with the closest calling relationship to the first instruction.

17. The method according to claim 16, characterized in that, The method further includes: If the target count value is less than or equal to the second preset value, or if the return address of the first instruction is different from the return address of the second preset number of target second instructions, the target subsystem determines the stack frame pointer of the first instruction based on the target stack frame pointer. The target subsystem increments the target count value by 1 to obtain a new target count value. The target subsystem repeatedly executes the stack frame pointer of the first instruction as the target stack frame pointer.

18. An exception handling system, characterized in that, The exception handling system includes an electronic device and a server, wherein the electronic device is used to execute the exception handling method as described in any one of claims 1-17.

19. An electronic device, characterized in that, The electronic device includes a memory and one or more processors; the memory and the processors are coupled; the processors run a target subsystem, and the memory stores computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the method as described in any one of claims 1 to 17.

20. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 17.

21. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 17.

Images