Dump data generation method, electronic device and storage medium

Abstract

The present application provides a dump data generation method, an electronic device and a storage medium, and relates to the field of communication technology. The electronic device includes an application processor subsystem and multiple additional subsystems. The electronic device receives a subsystem restart SSR interrupt message, and the SSR interrupt message is triggered by a first abnormal event occurring in a target subsystem among multiple additional subsystems. In response to the SSR interrupt message, the electronic device obtains the event information of the first abnormal event, and then determines whether the event information of the first abnormal event matches at least one configuration record of a pre-stored configuration file. If the event information of the first abnormal event matches at least one configuration record of the configuration file, the electronic device generates complete dump data. In this way, the electronic device can provide more comprehensive information when the target subsystem is abnormal through the complete dump data, which facilitates the system debugging of the electronic device.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communication technology, and in particular to a dump data generation method, an electronic device, and a storage medium. Background Art

[0002] In order to meet the needs of electronic equipment functional diversity, the operating system of the electronic equipment may include multiple additional subsystems. For example, taking the electronic equipment as a mobile phone, the mobile phone includes Wi-Fi, modem, audio digital signal processor (ADSP), compute digital signal processor (CDSP), sensor (spli) and other additional subsystems run by multiple additional processors.

[0003] In some cases, the subsystems of electronic devices may experience abnormalities. For example, Wi-Fi may crash due to factors such as the communication environment. In order to analyze the cause of the subsystem abnormality, the electronic device will automatically generate a subsystem restart (SSR) dump data (referred to as SSR dump data) when the subsystem is abnormal. SSR dump data can record relevant information when the subsystem is abnormal. Developers can use SSR dump data to analyze the problem that caused the subsystem abnormality.

[0004] However, the SSR dump data generated when a subsystem exception occurs provides limited information. In some cases, it is difficult for developers to locate the problem that caused the subsystem exception through the SSR dump data, which brings inconvenience to system debugging. Summary of the invention

[0005] The embodiments of the present application provide a dump data generation method, an electronic device, and a storage medium, which are used to provide more comprehensive dump data when an abnormality occurs in a subsystem, so as to facilitate locating the problem causing the abnormality in the subsystem.

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

[0007] In a first aspect, a dump data generation method is provided, which is applied to an electronic device. The electronic device includes an application processor subsystem and multiple additional subsystems. When a first abnormal event occurs in a target subsystem among multiple additional subsystems of the electronic device, the electronic device receives a subsystem restart SSR interrupt message triggered by the first abnormal event of the target subsystem. In response to the SSR interrupt message, the electronic device obtains event information of the first abnormal event, and the event information includes the cause of the event and the subsystem type. Further, the electronic device determines whether the event information of the first abnormal event matches at least one configuration record of a pre-stored configuration file. The configuration record is used to indicate an abnormal event for providing complete dump data. If the event information of the first abnormal event matches at least one configuration record of the configuration file, it can be considered that the first abnormal event is an abnormal event that requires providing complete main dump data. In this case, the electronic device generates complete dump data. The complete dump data includes memory mirror data of the application processor subsystem and memory mirror data of the target subsystem.

[0008] By completely dumping the data, developers can obtain more comprehensive information when a subsystem exception occurs, locate subsystem exception problems that are difficult to locate through SSR dump data, and facilitate system debugging of electronic equipment.

[0009] In a possible implementation manner of the first aspect, if the event information of the first abnormal event matches at least one configuration record of the pre-stored configuration file, the electronic device triggers a panic event at the operating system level and generates complete dump data.

[0010] In the method, if the event information of the first abnormal event matches at least one configuration record of the pre-stored configuration file, the electronic device can convert the first abnormal event into an operating system-level panic event, and generate complete dump data triggered by the panic event.

[0011] In another possible implementation manner of the first aspect, before triggering the panic event, the electronic device may further record event information of the first abnormal event as event information of the panic event.

[0012] In this way, the electronic device may describe the panic event triggered by the electronic device by using the event information of the first abnormal event, so as to provide a basis for classifying the panic event by using the event information of the first abnormal event.

[0013] In another possible implementation of the first aspect, in response to the SSR interrupt message, the electronic device may further shield other interrupt requests. In the case of shielding other interrupt requests, the electronic device generates complete dump data.

[0014] In this method, the electronic device can shield the interference of other interrupt messages on the panic event processing, so as to obtain the memory mirror data closest to the time when the first abnormal event occurs in the target subsystem.

[0015] In another possible implementation manner of the first aspect, the electronic device may copy memory data of the application processor subsystem and memory data of the target subsystem to generate complete dump data.

[0016] In this method, the complete dump data is obtained by copying the memory data of the application processor subsystem and the memory data of the target subsystem, and can provide more comprehensive information.

[0017] In another possible implementation of the first aspect, if the event information of the first abnormal event does not match any configuration record of the pre-stored configuration file, the electronic device generates SSR dump data, which includes memory image data of the target subsystem.

[0018] In this method, if the event information of the first abnormal event does not match any configuration record in the configuration file, it indicates that the first abnormal event may be an abnormal event that can be located through SSR dump data. In this case, the electronic device only generates SSR dump data when the first abnormal event occurs in the target subsystem.

[0019] In another possible implementation of the first aspect, the electronic device may add a work task of the first abnormal event in a preset work queue, and then asynchronously process the work task of the first abnormal event in the preset work queue to generate SSR dump data.

[0020] In this way, the electronic device asynchronously executes the operation of generating SSR dump data through a preset work queue, which will not block the main thread currently running in the electronic device, reduce the delay of interrupt processing, and improve the response rate of the electronic device to interrupt messages.

[0021] In another possible implementation of the first aspect, before receiving the subsystem restart SSR interruption message, the electronic device also receives a push message sent by the first cloud device. The push message carries a configuration file or a path to obtain the configuration file. In response to the push message, the electronic device reads the configuration file and writes the configuration file into the memory.

[0022] In this way, developers can instruct the electronic device through the first cloud device to provide complete dump data of abnormal events as needed, which is flexible in configuration and convenient for debugging of the electronic device.

[0023] In another possible implementation of the first aspect, the electronic device further reports the first abnormal event to a second cloud device. The second cloud device is used to count abnormal events of the electronic device.

[0024] In this way, the second cloud device can collect statistics and manage abnormal events occurring in the electronic device, thus facilitating the debugging of the electronic device.

[0025] In another possible implementation of the first aspect, the multiple additional subsystems of the electronic device include a subsystem run by at least one additional processor among a modem, a Wi-Fi, an audio digital signal processor, and a computing digital signal processor.

[0026] In a second aspect, the present application provides an electronic device, which includes: a memory and one or more processors. The memory is coupled to the processor. The processor can run an application processor subsystem and multiple additional subsystems. The memory is used to store computer program code, and the computer program code includes computer instructions. When the computer instructions are executed by the processor, the electronic device performs the following steps: receiving a subsystem restart SSR interrupt message; wherein the SSR interrupt message is triggered by a first abnormal event occurring in a target subsystem among multiple additional subsystems; in response to the SSR interrupt message, obtaining event information of the first abnormal event; wherein the event information includes an event cause and a subsystem type; determining whether the event information of the first abnormal event matches at least one configuration record of a pre-stored configuration file; wherein the configuration record is used to indicate an abnormal event that provides complete dump data; if the event information of the first abnormal event matches at least one configuration record of the configuration file, generating complete dump data; wherein the complete dump data includes memory mirror data of the application processor subsystem and memory mirror data of the target subsystem.

[0027] In a possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: if the event information of the first abnormal event matches at least one configuration record of the configuration file, a panic event at the operating system level is triggered, and a complete dump data is generated.

[0028] In another possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: if the event information of the first abnormal event matches at least one configuration record of the configuration file, a panic event at the operating system level is triggered, and a complete dump data is generated.

[0029] In another possible implementation manner of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: recording the event information of the first abnormal event as event information of a panic event.

[0030] In another possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: in response to the SSR interrupt message, shielding other interrupt requests; and generating complete dump data when shielding other interrupt requests.

[0031] In another possible implementation manner of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: copying the memory data of the application processor subsystem and the memory data of the target subsystem to generate complete dump data.

[0032] In another possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: if the event information of the first abnormal event does not match any configuration record of the configuration file, SSR dump data is generated; wherein the SSR dump data includes memory mirror data of the target subsystem.

[0033] In another possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: adding a work task of the first abnormal event to a preset work queue; asynchronously processing the work task of the first abnormal event in the preset work queue to generate SSR dump data.

[0034] In another possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device also performs the following steps: receiving a push message sent by the first cloud device; wherein the push message carries a configuration file or a path to obtain the configuration file; in response to the push message, reading the configuration file, and writing the configuration file into the memory.

[0035] In another possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: reporting the first abnormal event to a second cloud device; wherein the second cloud device is used to count the abnormal events of the electronic device.

[0036] In another possible implementation manner of the second aspect, the multiple additional subsystems include a subsystem run by at least one additional processor among a modem, a Wi-Fi, an audio digital signal processor, and a computing digital signal processor.

[0037] In a third aspect, the present application provides a computer-readable storage medium, comprising computer instructions, which, when executed on an electronic device, enables the electronic device to execute the method described in the first aspect and any possible implementation thereof.

[0038] In a fourth aspect, the present application provides a computer program product including program instructions, which, when executed on a computer, enables the computer to execute the method described in the first aspect and any possible implementation thereof. For example, the computer may be the electronic device described above.

[0039] In a fifth aspect, the present application provides a chip system, which is applied to an electronic device. The chip system includes an interface circuit and a processor. The interface circuit and the processor are interconnected by a line. The interface circuit is used to receive a signal from a memory and send a signal to the processor, the signal including a computer instruction stored in the memory. When the processor executes the computer instruction, the electronic device executes the method described in the first aspect and any possible implementation thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 A schematic diagram of generating SSR dump data provided in an embodiment of the present application;

[0041] Figure 2 A hardware structure block diagram of an example of an electronic device provided in an embodiment of the present application;

[0042] Figure 3 A software structure block diagram of an example of an electronic device provided in an embodiment of the present application;

[0043] Figure 4 A flowchart of an example of a method for generating dump data provided in an embodiment of the present application;

[0044] Figure 5 A flowchart of an example of a first cloud device sending a push message to a mobile phone provided in an embodiment of the present application;

[0045] Figure 6 A schematic diagram of an example of a configuration interface provided in an embodiment of the present application;

[0046] Figure 7 A flowchart of an example of saving a configuration file provided in an embodiment of the present application;

[0047] Figure 8 A schematic diagram of an example of a configuration file provided in an embodiment of the present application;

[0048] Fig. 9 A flowchart of another example of a method for generating dump data provided in an embodiment of the present application;

[0049] Fig.10 A schematic diagram of an example of an abnormal event interface provided in an embodiment of the present application;

[0050] Fig.11A schematic diagram of an example of a method for generating dump data provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] The embodiment of the present application provides a dump data generation method, which is applied to an electronic device. The system on a chip (SoC) of the electronic device usually includes a main application processor subsystem (APSS) and multiple additional subsystems.

[0052] When an exception occurs in an additional subsystem of an electronic device, the electronic device will start the subsystem restart (SubsystemRestart, SSR) mechanism and generate SSR dump data. The SSR dump data records relevant information when the subsystem exception occurs. For example, the SSR dump data records relevant information such as process information, register information, stack pointer, exception information, etc. when the subsystem exception occurs. Through the SSR dump data, developers can analyze the problem of the subsystem exception, so that they can debug the exception that occurred in the subsystem.

[0053] For example, if the electronic device is a mobile phone, the system on chip of the mobile phone includes an application processor subsystem running on an application processor, and additional subsystems running on multiple additional processors such as a modem, Wi-Fi, sensor, and audio digital signal processor. Figure 1 As shown, the application processor subsystem of the mobile phone includes a local service layer (native layer) (also called a system library) and a kernel layer (kernel layer).

[0054] The native layer of the mobile phone includes the initialization process (init process) and other user processes started by the init process. The init process is the first user process started by the application processor subsystem. Through the init process, the mobile phone can start other user processes, such as the subsystem restart SSR configuration service. The SSR configuration service can access the kernel layer through system files (such as \sys) to configure the SSR driver. The SSR configuration service can also determine whether to restart the subsystem when an exception occurs in the subsystem.

[0055] The kernel layer of the mobile phone includes system files and SSR drivers. The system files include some system configuration files, system startup files, etc. The SSR configuration service can configure the SSR driver through the system files. The SSR driver includes a communication interface. For example, the SSR driver may include a communication interface. The SSR configuration service in the native layer and the SSR driver in the kernel layer can communicate through the communication interface. The SSR driver can complete the registration of additional subsystems. By registering the additional subsystem with the SSR driver, the SSR driver can handle exceptions that occur in the additional subsystem.

[0056] Take the case where an abnormal event (such as a fatal error or an abnormal event detected by a watchdog mechanism) occurs in a modem in an additional subsystem as an example. When an abnormal event occurs in the modem, an interrupt message will be sent to the application processor subsystem. In response to the interrupt message, the SSR driver copies the memory data of the modem when the abnormal event occurs in the modem to the shared memory to obtain the SSR dump data of the modem. In addition, the SSR driver can also obtain the event information (such as the cause of the event, the subsystem type, etc.) of the abnormal event that occurs in the modem at the top of the stack or in the interrupt message, and store the event information in the dump directory of the shared memory. Alternatively, the event information can also be recorded in the memory process log to generate a system log that records the event information of the abnormal event that occurs in the modem. Since the information recorded in the system log is limited, the dump module of the SSR driver can also export the SSR dump data stored in the shared memory to this storage. The dump module can obtain the SSR dump data from the shared memory and then send the SSR dump data to the system file.

[0057] The initialization process in the local service layer can also start the subsystem random dump service to export SSR dump data when an exception occurs in the modem. Further, the subsystem random dump service can read the SSR dump data in the system file and write the SSR dump data to the local storage space, thereby exporting the SSR dump data to the local storage.

[0058] After the mobile phone writes the SSR dump data into the local storage space, the developer can obtain the SSR dump data of the modem in the local storage space. Through the SSR dump data of the modem, the developer can clearly identify the problem that caused the abnormality of the modem, so as to debug the abnormal event of the modem.

[0059] However, the information provided by SSR dump data is limited. In some cases, developers also need to combine the full dump data of the mobile phone operating system to analyze the problem that caused the subsystem abnormality. For example, about 25% of modem problems require supplementary full dump data. For WiFi failures, developers can hardly solve them through SSR dump data, and most problems require supplementary full dump data. For failures in other subsystems such as ADSP and CDSP, some problems also rely on full dump data for developers to locate the problem of subsystem abnormality. If the SSR dump data of a subsystem does not provide enough information, then in the absence of full dump data, it is difficult for developers to locate the problem that caused the subsystem abnormality, which brings inconvenience to system debugging.

[0060] In view of this, an embodiment of the present application provides a method for generating dump data, and a configuration file can be pre-stored in an electronic device. The configuration file includes at least one configuration record, and each configuration record is used to indicate an abnormal event that requires the provision of complete dump data. When a first abnormal event occurs in a target subsystem among multiple additional subsystems of an electronic device, the electronic device receives an SSR interrupt message triggered by the first abnormal event of the target subsystem. In response to the SSR interrupt message, the electronic device matches the event information of the first abnormal event occurring in the target subsystem with at least one configuration record in a pre-stored configuration file. If the event information of the first abnormal event matches any set of configuration records in the configuration file, it can be considered that the first abnormal event is an abnormal event that requires the provision of complete main dump data. In this case, the electronic device can generate complete dump data.

[0061] In addition to recording the memory image data of the target subsystem, the full dump data also includes the memory image data of the main application processor subsystem of the electronic device. Through the full dump data, developers can obtain more comprehensive information when a subsystem exception occurs, locate subsystem exceptions that are difficult to locate through SSR dump data, and facilitate system debugging of electronic devices.

[0062] For example, the electronic device described in the embodiments of the present application may be a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) / virtual reality (VR) device, a media player, a wearable device, etc. The embodiments of the present application do not impose any special restrictions on the specific form of the electronic device.

[0063] In the embodiment of the present application, the electronic device is a mobile phone 100 as an example, and the hardware structure of the electronic device is introduced through the mobile phone 100. Figure 2 As shown, the mobile phone 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0064] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), a driver processor, etc. Different processing units may be independent devices or integrated into one or more processors. The processor 110 may be the nerve center and command center of the mobile phone 100. The processor 110 may generate an operation control signal according to the instruction opcode and the timing signal to complete the control of fetching and executing instructions.

[0065] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0066] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the mobile phone 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0067] The internal memory 121 may be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the mobile phone 100 by running the instructions stored in the internal memory 121. For example, in an embodiment of the present application, the processor 110 may execute the instructions stored in the internal memory 121, and the internal memory 121 may include a program storage area and a data storage area.

[0068] The program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), a configuration file of the motor 191, etc. The data storage area may store data created during the use of the mobile phone 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0069] The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. While the charging management module 140 charges the battery 142, it can also power the mobile phone 100 through the power management module 141.

[0070] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193, and the wireless communication module 160. In some embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0071] The wireless communication function of the mobile phone 100 can be implemented by the antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modulation and demodulation processor, and baseband processor, etc. In some embodiments, the antenna 1 of the mobile phone 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the mobile phone 100 can communicate with the network and other devices through wireless communication technologies.

[0072] The antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the mobile phone 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization rate of the antennas. For example: the antenna 1 can be multiplexed as the diversity antenna of the wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0073] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc. applied to the mobile phone 100. The mobile communication module 150 can include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and perform filtering, amplification and other processing on the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation.

[0074] The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves through the antenna 1 and radiate it out. In some embodiments, at least some functional modules of the mobile communication module 150 can be disposed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 can be disposed in the same device.

[0075] The wireless communication module 160 can provide solutions for wireless communications 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), infrared technology (IR), etc. applied to the mobile phone 100.

[0076] The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 may also receive a signal to be sent from the processor 110, modulate the signal, amplify the signal, and convert it into an electromagnetic wave for radiation via the antenna 2.

[0077] The mobile phone 100 can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the earphone interface 170D, and the application processor.

[0078] The sensor module 180 may include sensors such as a pressure sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a Hall sensor, a touch sensor, an ambient light sensor, and a bone conduction sensor. The mobile phone 100 may collect various data through the sensor module 180 .

[0079] The mobile phone 100 implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0080] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), MiniLED, MicroLED, Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

[0081] The mobile phone 100 can realize the shooting function through the ISP, the camera 193, the video codec, the GPU, the display screen 194 and the application processor. The ISP is used to process the data fed back by the camera 193. The camera 193 is used to capture a still image or a video. In some embodiments, the mobile phone 100 may include one or more cameras 193.

[0082] The button 190 includes a power button, a volume button, etc. The button 190 may be a mechanical button. It may also be a touch button. The motor 191 may generate a vibration prompt. The motor 191 may be used for an incoming call vibration prompt or for touch vibration feedback. The indicator 192 may be an indicator light, which may be used to indicate the charging status, the change in power, or may be used to indicate messages, missed calls, notifications, etc.

[0083] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to or disconnected from the mobile phone 100 by inserting the SIM card interface 195 or pulling the SIM card interface 195 out. The mobile phone 100 can support one or more SIM card interfaces. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc.

[0084] It is understandable that the interface connection relationship between the modules illustrated in this embodiment is only a schematic illustration and does not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also include more or fewer modules than those provided in the above embodiments, and different interface connection methods in the above embodiments may be used between the modules, or a combination of multiple interface connection methods. The hardware structure of the electronic device provided in the embodiments of the present application can also refer to the hardware structure of the mobile phone 100 as shown in the figure. The methods in the following embodiments can all be implemented in an electronic device having the above hardware structure.

[0085] The operating system of the mobile phone 100 may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture or a cloud architecture. The present application embodiment takes the layered architecture of the Android system as an example to illustrate the software structure of the mobile phone 100.

[0086] Figure 3 1 is a software structure diagram of an embodiment of the present application, taking the electronic device as an application processor of a mobile phone 100 as an example. The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system may include an application layer, an application framework layer, an Android runtime (Android runtime), a system library, and a kernel layer.

[0087] The application layer may include a series of application packages. For example, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications, and the present application embodiment does not impose any restrictions on this.

[0088] The application framework layer provides an application programming interface (API) and a programming framework for the application programs of the application layer. The application framework layer includes some predefined functions. For example, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, and a notification manager, etc., and the embodiments of the present application do not impose any restrictions on this.

[0089] The Android runtime consists of a core library and a virtual machine. The Android runtime is responsible for scheduling and management of the Android system. The core library consists of two parts: one is the function that the Java language needs to call, and the other is the Android core library. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0090] The system library can include multiple functional modules. For example: surface manager, media library, 3D graphics processing library (for example: OpenGL ES), 2D graphics engine (for example: SGL), etc. The system library is also called the local service layer, that is, the system library can be Figure 1 The local service layer of the application processor subsystem.

[0091] The kernel layer is the layer between hardware and software. The kernel layer includes drivers and system services. Drivers include subsystem drivers corresponding to the hardware. For example, drivers include display drivers, camera drivers, audio drivers, sensor drivers, etc. The kernel layer corresponds to Figure 1 The kernel layer of the application processor subsystem in the application processor subsystem. The kernel layer may also include the SSR driver and the drivers of each additional processor.

[0092] The following takes the mobile phone as an example to describe the method provided by the embodiment of the present application. Figure 4 As shown, the method provided in the embodiment of the present application includes the following steps:

[0093] S401, the first cloud device sends a push message to the mobile phone.

[0094] The first cloud device is a cloud device used to send push messages to the mobile phone. For example, the first cloud device can be a cloud device such as a cloud server, a cloud computer, etc. The first cloud device can send a push message to the mobile phone. The push message can include a configuration file or a path to obtain the configuration file. The configuration file includes at least one configuration record. A configuration record includes event information of an abnormal event that requires full storage data to be provided.

[0095] In some implementations, the event information includes the event cause and subsystem type of the abnormal event. The event cause may indicate the abnormal cause reported by the subsystem. For example, the event cause may be a subsystem crash, a subsystem non-response, etc. The subsystem type may indicate the subsystem in which the abnormal event occurred. For example, the subsystem type may be a modem, Wi-Fi, etc.

[0096] In some implementations, the first cloud device may receive a configuration request sent by the mobile phone. In response to the configuration request, the first cloud device sends a push message carrying the configuration file or the path to obtain the configuration file to the mobile phone.

[0097] In some implementations, the first cloud device may receive input information input by the developer. After receiving the input information from the developer, a push message is sent to the mobile phone. Figure 5 As shown, before S401, the method provided in the embodiment of the present application may further include the following steps:

[0098] S501, the first cloud device receives input information from a developer.

[0099] The first cloud device may provide a configuration interface for setting a configuration file. The first cloud device may receive input information from a developer in the configuration interface. The input information may include a configuration file of event information of at least one abnormal event or an acquisition path of the configuration file.

[0100] For example, the configuration interface of the first cloud device may provide file setting items of the configuration file. The file setting items of the configuration file include the file identifier of the configuration file (such as configuration 1, configuration 2, etc.), download method (such as hypertext transfer security protocol https), acquisition path (such as https: / / configdownload-drcn.xxx.com, https: / / configdownload-drcn.xaa.com, etc.), version number (such as 101001, 101002, etc.), and other setting items. The first cloud device may receive input information corresponding to each file setting item entered by the developer in the configuration interface. Figure 6As shown, after the first cloud device receives the input information from the developer, the first file setting item displayed in the configuration interface (corresponding to a line under the configuration file) indicates: the information identifier is configuration 1, the download method is https, the acquisition path is https: / / configdownload-drcn.xxx.com, and the version number is a configuration file 101001.

[0101] In order to provide a valid configuration file to the mobile phone, the first cloud device can also determine whether the input information of the developer meets the preset configuration conditions. After S501, the first cloud device can perform step S502:

[0102] S502: The first cloud device determines whether the input information meets the preset configuration conditions.

[0103] The preset configuration conditions can be set according to the actual application scenario or demand. For example, the input information received by the first cloud device includes a configuration file for indicating at least one abnormal event. The preset configuration condition may be that the abnormal event indicated by the input information belongs to an abnormal event that is difficult to locate through SSR dump data. The first cloud device may pre-store an event list of abnormal events that are difficult to locate through SSR dump data. After receiving the input information from the developer, the first cloud device may search the event list to determine whether the abnormal event indicated by the input information is in the event list. If all the abnormal events indicated by the input information are in the event list, it can be considered that the developer's input information meets the preset configuration conditions.

[0104] For another example, the input information received by the first cloud device includes an acquisition path of a configuration file. The preset configuration condition may be that the acquisition path of the configuration file is a valid acquisition path. The first cloud device may verify the validity of the acquisition path of the configuration file, thereby ensuring that the acquisition path pushed to the mobile phone is valid.

[0105] In some implementations, the preset configuration conditions may also include one or more of the following conditions: the data size of each configuration record in the configuration file is less than the preset data size; the total number of configuration records in the configuration file is less than the preset number of configuration records; the input information is identifiable information; etc. The embodiments of the present application do not limit the preset configuration conditions.

[0106] If the input information received by the first cloud device meets the preset configuration condition, the first cloud device may execute S503.

[0107] If the input information received by the first cloud device does not meet the preset configuration condition, the first cloud device may execute S504.

[0108] S503, the first cloud device sends a push message to the mobile phone.

[0109] If the input information received by the first cloud device meets the preset configuration condition, the first cloud device can send a push message to the mobile phone. The push message can carry the above configuration file or the acquisition path of the above configuration file.

[0110] S504: The first cloud device does not send a push message to the mobile phone.

[0111] If the configuration file does not meet the preset configuration conditions, the first cloud device does not send a push message to the mobile phone.

[0112] In some implementations, the first cloud device may also provide a conditional setting item of a preset configuration condition in the configuration interface, so that the first cloud device may receive input information including the preset configuration condition in the configuration interface. In this way, developers may set the preset configuration condition in the configuration interface provided by the first cloud device as required.

[0113] Exemplarily, the configuration interface of the first cloud device may also provide conditional setting items for preset configuration conditions. The conditional setting items for preset configuration conditions include key items, attribute values, etc. Among them, the key items may be device name, system type, compatible version, etc. Developers may set the preset configuration conditions according to actual needs. Figure 6 As shown, after the first cloud device receives the input information from the developer, the first condition setting item displayed in the configuration interface (corresponding to a line under the configuration condition) indicates that the key item is the system type, and the attribute value is the preset configuration condition of the chip system 1.

[0114] S402: The mobile phone reads and saves a configuration file including at least one configuration record in response to a push message sent by the first cloud device.

[0115] After receiving the push message sent by the first cloud device, the mobile phone can obtain a configuration file including at least one configuration record and write the obtained configuration file into a preset configuration node. For example, the mobile phone can write the configuration file into a preset configuration node in the system file.

[0116] Exemplarily, the mobile phone's application processor subsystem includes a cloud push configuration service, a subsystem log service, and a preset configuration node. Figure 7As shown, after the application processor subsystem of the mobile phone receives the push message sent by the first cloud device through the cloud push configuration service, in S701, the cloud push configuration service of the application processor subsystem reads the configuration file. Then, in S702, the cloud push configuration service of the application processor subsystem sends a communication instruction to the subsystem log service through the binder mechanism, instructing the subsystem log service to save the configuration file. After the subsystem log service of the application processor subsystem receives the communication instruction sent by the cloud push configuration service, in S703, the subsystem log service of the application processor subsystem writes the configuration file into the preset configuration node.

[0117] Here, the binder mechanism is a mechanism for communication between processes. Through the binder mechanism, cross-process communication between the cloud push configuration service and the subsystem log service can be achieved.

[0118] In some implementations, the push message received by the mobile phone may carry a configuration file or a path to obtain the configuration file. If the push message includes the configuration file, the mobile phone may directly obtain the configuration file in the push message. If the push message includes a path to obtain the configuration file, the mobile phone may obtain the configuration file through the path.

[0119] In some implementations, after obtaining the configuration file, the mobile phone may also verify the configuration file to determine whether the configuration record in the configuration file meets the preset verification condition. If all the configuration records in the configuration file meet the preset verification condition, the mobile phone may save the obtained configuration file in the preset configuration node. If any configuration record in the configuration file does not meet the preset verification condition, the mobile phone may delete the configuration record in the configuration file and save the configuration file after deleting the configuration record in the preset configuration node.

[0120] Here, the preset verification condition can be set according to the implementation application scenario or requirement. For example, the preset verification condition can be that the data size of the configuration record is less than the preset data size (such as less than 256 bytes). For example, the preset verification condition can be that the total number of configuration records is less than the preset number of configuration records (such as less than 100).

[0121] For example, a mobile phone includes a cloud push configuration service. After obtaining the configuration file, the cloud push configuration service in the mobile phone can determine whether the data size of each configuration record in the obtained configuration file is less than 256 bytes (i.e., the preset data size). If the data size of any configuration record in the configuration file is less than 256 bytes, the cloud push configuration service of the mobile phone will write the verified configuration file to the preset configuration node. If a configuration record in the configuration file is greater than or equal to 256 bytes, the cloud push configuration service of the mobile phone will delete the configuration record and write the verified configuration file to the preset configuration node.

[0122] For example, the configuration file is as follows Figure 8 As shown. The configuration file includes 3 lines of configuration, namely, reason 1_xxxxx, reason 2_xxxxx, and reason 3_xxxxx. Each line of configuration corresponds to a configuration record. The data size of each configuration record is less than 256 bytes. The total number of configuration records in the configuration file is less than 100.

[0123] S403, the mobile phone receives an SSR interrupt message, where the interrupt message is triggered by a first abnormal event of the modem of the mobile phone.

[0124] In order to improve the stability and reliability of the modem, a detection mechanism can be set in the mobile phone to periodically detect the operating status of the modem, which can trigger the modem to send an SSR interrupt message when an abnormality occurs in the modem. The above detection period can be 10 milliseconds, 30 milliseconds, etc. For example, the mobile phone is equipped with a fatal mechanism and a watchdog mechanism to detect abnormal events such as crashes and stop responding of the modem. If an abnormal event is detected in the modem, the modem is triggered to send an SSR interrupt message to the application processor subsystem of the mobile phone.

[0125] The mobile phone's application processor subsystem receives an SSR interrupt message triggered by a first abnormal event, which can trigger the mobile phone's application processor subsystem to generate modem dump data and provide a modem memory image for the abnormal event that occurs in the modem.

[0126] For example, the application processor subsystem of a mobile phone may include a communication interface and a subsystem failure log module. Fig. 9 As shown, the application processor subsystem of the mobile phone can receive an SSR interrupt message triggered by a first abnormal event occurring in the modem (eg, in S901 , the communication interface of the application processor subsystem of the mobile phone receives the SSR interrupt message).

[0127] S404: In response to the SSR interrupt message, the mobile phone obtains event information of the first abnormal event.

[0128] The mobile phone responds to the SSR interrupt message triggered by the first abnormal event of the modem and obtains event information of the first abnormal event, wherein the event information includes the cause of the event and the subsystem type.

[0129] For example, the mobile phone's application processor subsystem receives an SSR interrupt message triggered by a first abnormal event of the modem. In response to the SSR interrupt message, the mobile phone's application processor subsystem can call an interrupt function to obtain the event cause of the first abnormal event of the modem at the top of the stack corresponding to the first abnormal event of the modem.

[0130] For another example, the SSR interrupt message may carry a subsystem type. The subsystem type identifier is used to indicate the subsystem in which the first abnormal event occurs. After the application processor subsystem of the mobile phone receives the SSR interrupt message triggered by the first abnormal event, the application processor subsystem may obtain the subsystem type used to indicate the modem in the received SSR interrupt message. Alternatively, the application processor subsystem of the mobile phone may exchange information with the modem through a preset communication interface. The application processor subsystem may determine whether the preset communication interface is called when receiving the SSR interrupt message triggered by the first abnormal event. If the preset communication interface is called, the application processor subsystem may confirm the subsystem type of the first abnormal event.

[0131] Exemplarily, the mobile phone's application processor subsystem includes a communication interface and a subsystem failure log module. The mobile phone's application processor subsystem responds to the SSR interrupt message and obtains event information (such as the first abnormal event) of the first abnormal event through the communication interface. Fig. 9 In S902, in response to the SSR interrupt message, the application processor subsystem obtains the event cause and subsystem type of the first abnormal event through the communication interface). After the application processor subsystem communication interface obtains the event information of the first abnormal event, the communication interface of the application processor subsystem notifies the subsystem failure log module of the event information of the first abnormal event (such as Fig. 9 In S903, the communication interface sends the event cause and subsystem type of the first abnormal event to the subsystem failure log module).

[0132] S405: The mobile phone determines whether the event information of the first abnormal event matches at least one configuration record of the pre-stored configuration file.

[0133] After obtaining the event information of the first abnormal event, the mobile phone can read the pre-saved configuration file in the preset configuration node, and match the event information of the first abnormal event with at least one configuration record in the pre-stored configuration file in sequence, to determine whether the event information of the first abnormal event matches at least one configuration record in the pre-stored configuration file.

[0134] For example, Fig. 9 In S904, the application processor subsystem of the mobile phone determines, through the subsystem failure log module, whether the event information of the first abnormal event matches at least one configuration record of the pre-stored configuration file.

[0135] A configuration record of the configuration file may include visible characters, invisible characters, and empty characters. Visible characters may include characters such as letters, numbers, and punctuation marks. Invisible characters may include invisible characters such as spaces, line feeds, and carriage returns. In order to improve the matching accuracy between the event information of the first abnormal event and the configuration record of the configuration file, in some implementations, the mobile phone may determine whether the event information of the first abnormal event and the matching characters of at least one configuration record of the configuration file are greater than or equal to a preset data amount. For example, the preset data amount may be set to 10 bytes.

[0136] If the number of matching characters between the event information of the first abnormal event and a configuration record is greater than or equal to a preset data amount, the first abnormal event can be considered to match the configuration record. If the number of matching characters between the event information of the first abnormal event and a configuration record is less than a preset data amount, the first abnormal event can be considered to not match the configuration record.

[0137] S406: If the event information of the first abnormal event matches a configuration record in a pre-stored configuration file, the mobile phone generates complete dump data.

[0138] If the event information of the first abnormal event matches at least one configuration record in the configuration file, it indicates that the first abnormal event is an abnormal event that is difficult to locate through the SSR dump data, and complete dump data needs to be provided. In this case, the mobile phone can generate complete dump data. For example, the mobile phone can suspend the execution of the currently processed task, copy the memory data of the current application processor subsystem and the memory data of the modem, and generate complete dump data. The mobile phone can save the generated complete dump data in the local storage space, so that the developer can obtain the complete dump data in the local storage space.

[0139] Here, the complete dump data is obtained by copying the memory data of the application processor subsystem and the memory data of the modem, and may include the memory mirror data of the application processor subsystem (i.e., a copy of the memory data of the application processor subsystem) and the memory mirror data of the modem (i.e., a copy of the memory data of the modem). It can be considered that the complete dump data includes the complete data associated with the first abnormal event when the first abnormal event occurs in the modem. The complete dump data can provide more comprehensive information. Through the complete dump data, developers can locate subsystem abnormal problems that are difficult to locate through SSR dump data, providing convenience for system debugging of mobile phones.

[0140] In order to generate complete dump data corresponding to the mobile phone with more information, in some implementations, the mobile phone converts the first abnormal event into a panic event at the operating system level when the event information of the first abnormal event matches at least one configuration record in the configuration file, and generates complete dump data triggered by the panic event. Specifically, if the event information of the first abnormal event matches at least one configuration record in the configuration file, the mobile phone can trigger a panic event to generate complete dump data of the mobile phone including the memory image data of the application processor subsystem and the modem.

[0141] For example, Fig. 9 In S905, if the event information of the first abnormal event matches at least one configuration record in the configuration file, the application processor subsystem of the mobile phone triggers a panic event through the subsystem failure log module to generate complete dump data.

[0142] Here, a panic event is an abnormal event at the operating system level, indicating that a serious crash has occurred in the current operating system. In the event of a panic event, the mobile phone will generate a complete dump data of the current operating system so that developers can locate and analyze the problem that caused the panic event through the complete dump data. In this implementation, if the event information of the first abnormal event matches at least one configuration record in the configuration file, the mobile phone can treat the first abnormal event as a panic event, and instead execute the processing flow of the panic event to generate a complete dump data of the operating system. In this way, for abnormal events that occur in the subsystem and are difficult to locate through SSR dump data, the mobile phone can process the abnormal events that occur in the subsystem as panic events that occur in the operating system, and provide complete conversion data corresponding to the memory data of the application processor subsystem and modem.

[0143] In some implementations, if the event information of the first abnormal event matches at least one configuration record of the configuration file, before triggering the panic event, the mobile phone can also record the event information of the first abnormal event as the event information of the panic event. In this way, the mobile phone can convert the first abnormal event occurring in the modem into a panic event occurring in the operating system. The event information of the first abnormal event can be used to describe the panic event triggered by the mobile phone to provide a basis for the classification of the panic event. Among them, the process of classifying the panic event using the event information can refer to the detailed description in the subsequent embodiments, which will not be repeated here.

[0144] In order to retain the memory image data of the operating system when the first abnormal event occurs in the modem as much as possible and to be close to the fault scene of the first abnormal event, in some implementations, the mobile phone can generate complete dump data triggered by the first abnormal event while shielding other interrupt requests.

[0145] When the mobile phone blocks other interrupt requests, even if it receives interrupt messages triggered by other subsystems or hardware devices, it will not respond to these interrupt messages immediately. Instead, after the mobile phone generates the complete dump data triggered by the first abnormal event, the mobile phone will respond to the interrupt messages triggered by other subsystems or hardware devices. This processing method can also be called the processing method above the interrupt.

[0146] It is understandable that for an interrupt handling process triggered by an interrupt message, it can be divided into the interrupt context and the interrupt context. For tasks that need to be processed immediately in the interrupt handling process, they can be executed in the interrupt context. Tasks executed in the interrupt context will not be interrupted by other interrupts. For tasks that can be processed later in the interrupt process, they can be executed in the interrupt context. In this way, the mobile phone can switch to execute other tasks before executing the tasks in the interrupt context.

[0147] A panic event is a relatively serious system-level abnormal event, so the complete dump data triggered by the panic event can be executed in the interrupt context to shield other interrupt messages from disturbing the panic event processing, thereby obtaining the memory image data closest to the time when the first abnormal event occurred in the modem.

[0148] Since the generation of the complete dump data may take a long time, it may affect the normal operation of the mobile phone operating system. In order to reduce the impact of the complete dump data triggered by the subsystem exception on the entire operating system, in some implementations, after the complete dump data is generated, the mobile phone can delete the configuration record matching the event information of the first abnormal event in the configuration file.

[0149] In this way, when the first abnormal event occurs again in the modem of the mobile phone, since there is no configuration record matching the event information of the first abnormal event in the configuration file, the mobile phone can generate the SSR dump data of the first abnormal event. In this way, the number of times that the abnormal event occurs in the additional subsystem of the mobile phone and triggers the complete dump data can be reduced, and the impact on other additional subsystems and application processor subsystems of the mobile phone can be reduced.

[0150] S407: If the event information of the first abnormal event does not match any configuration record in the configuration file, the mobile phone generates SSR dump data of the modem.

[0151] If the event information of the first abnormal event does not match any configuration record in the configuration file, it indicates that the first abnormal event may be an abnormal event that can be located through SSR dump data, and only the SSR dump data when the modem has the first abnormal event is provided. In this case, the mobile phone can obtain the memory image data of the modem and generate the SSR dump data of the modem.

[0152] The SSR dump data includes the memory image data of the modem. The SSR dump data generated by the mobile phone can be saved in the shared memory or local storage space. Developers can obtain the SSR dump data when the first abnormal event occurs in the modem in the shared memory or local storage space of the mobile phone.

[0153] In order to reduce the impact of generating SSR dump data on other tasks, in some implementations, the mobile phone can asynchronously generate SSR dump data through a preset work queue. The mobile phone can add a work task of the first abnormal event in the preset work queue. The mobile phone can asynchronously process the work task of the first abnormal event in the preset work queue and generate SSR dump data corresponding to the first abnormal event.

[0154] The preset work queue may be an existing work queue in the operating system of the mobile phone. In some implementations, if the event information of the first abnormal event does not match any configuration record in the configuration file, the mobile phone may also create a new work queue to obtain the preset work queue. The preset work queue is a mechanism for asynchronously processing work tasks.

[0155] The task of asynchronously processing the first abnormal event can be understood as that during the process of executing the interrupt processing corresponding to the interrupt message triggered by the first abnormal event, if the mobile phone also receives an interrupt message triggered by other subsystems or hardware devices, the mobile phone can immediately respond to the interrupt message triggered by other subsystems or hardware devices, and later perform the operation of generating SSR dump data. This interrupt processing method can also be called the processing method in the context of the interrupt.

[0156] For example, Fig. 9 In S906, if the event information of the first abnormal event does not match any configuration record in the configuration file, the application processor subsystem of the mobile phone asynchronously generates SSR dump data through the subsystem failure log module through the preset work queue.

[0157] In this way, the operation of generating SSR dump data will not block the main thread currently running on the mobile phone, reduce the delay of interrupt processing, and improve the response rate of the mobile phone to interrupt messages.

[0158] It is understandable that when the first abnormal event occurs in the modem of the mobile phone, the application processor subsystem of the mobile phone can be in a normal operating state. After the application processor subsystem of the mobile phone receives the interrupt message triggered by the first abnormal event, the application processor subsystem suspends the currently running program and immediately responds to the interrupt message triggered by the first abnormal event. As for the operation of generating SSR dump data, it takes a long time for the mobile phone to generate SSR dump data. In addition, after the first abnormal event occurs in the modem, the memory data of the modem changes very little, so the delay in generating SSR dump data has little effect on the validity of the SSR dump data. Therefore, the application processor subsystem of the mobile phone can perform the operation of generating SSR dump data in the interrupt context of the interrupt processing of the first abnormal event. In the case where the event information of the first abnormal event does not match any configuration record of the configuration file, the SSR dump data is asynchronously generated through the preset work queue.

[0159] In order to promptly notify the developer of the first abnormal event that occurred in the modem, in some implementations, the mobile phone can report the first abnormal event, so that the developer can promptly understand the first abnormal event that occurred in the modem. Specifically, the method provided in the embodiment of the present application may also include the following steps:

[0160] S408, the mobile phone reports the first abnormal event to the second cloud device.

[0161] The second cloud device can be used to count abnormal events of the mobile phone. After generating the complete dump data or SSR dump data of the first abnormal event occurring in the modem, the mobile phone can report the first abnormal event to the second cloud device and report the event information of the first abnormal event to the second cloud device.

[0162] In addition to the cause of the event and the subsystem category, the event information of the first abnormal event may also include other information such as time and central processing unit (CPU) number. In order to facilitate the second cloud device to classify the first abnormal event, in some implementations, the mobile phone can delete other information except the cause of the event and the subsystem type in the event information of the first abnormal event before reporting the event information of the first abnormal event to the second cloud device. The mobile phone then sends the event information of the first abnormal event after deleting other information to the second cloud device. In this way, the mobile phone can streamline the event information of the first abnormal event reported to the second cloud device, thereby improving the efficiency of the second cloud device in classifying the first abnormal event through the event information of the first abnormal event.

[0163] In some implementations, in order to enable the second cloud device to obtain more comprehensive information about the first abnormal event, the mobile phone can also report the complete dump data or SSR dump data of the first abnormal event. For example, after the mobile phone generates the complete dump data of the first abnormal event, that is, after S406, the mobile phone can send the event information and complete dump data of the first abnormal event to the second cloud device. For another example, after the mobile phone generates the SSR dump data of the first abnormal event, that is, after S407, the mobile phone sends the event information and SSR dump data of the first abnormal event to the second cloud device.

[0164] After the second cloud device receives the event information of the first abnormal event, it can also classify the first abnormal event according to the event information of the first abnormal event. For example, the second cloud device can classify the first abnormal event into the event category of abnormal event triggered by modem according to the subsystem category included in the event information of the first abnormal event. For another example, the second cloud device can classify the first abnormal event into the event category of the same event cause according to the event cause included in the event information of the first abnormal event.

[0165] In order for developers to obtain relevant information about abnormal events and debug abnormal events, in some implementations, the second cloud device may also provide a visual abnormal event interface. The abnormal event interface may display abnormal event records corresponding to each abnormal event. In this way, developers can understand abnormal events that occur in the operating system of the mobile phone, and thus debug abnormal events that occur in the mobile phone.

[0166] In some implementations, the above-mentioned abnormal event interface may also provide operation items for abnormal event records. For example, the abnormal event interface may include operation items such as edit, clear, delete, configure responsible person, and problem push. Among them, the edit operation item is used to edit the abnormal event record of the abnormal event. The clear operation item is used to clear the abnormal event records of all abnormal events. The delete operation item is used to delete the selected abnormal event record. The configure responsible person operation item is used to configure the person responsible for the abnormal event. The problem push operation item is used to send a push notification of the abnormal event to other devices or addresses (such as the first cloud device or the mailbox of the responsible person).

[0167] For example, the abnormal event interface provided by the second cloud device is as follows: Fig.10As shown. It can be seen that in the abnormal event interface provided by the second cloud device, multiple abnormal event records (corresponding to a line of data) are displayed. Each abnormal event record includes dump data (such as complete dump data 01, complete dump data 02, etc.) (which can be shown in link form), event name (such as panic, wlan, etc.) and event cause (such as modem crash reset, wlan crash reset, etc.). Among them, the dump data can be opened through the corresponding link. The event name is the name of the abnormal event, for example, a panic event, an error (bug) event, an unknown address (unknown_addr) event, etc. The event cause is the reason for triggering the abnormal event, for example, a subsystem restart, a startup failure, an attempt to terminate the init process, etc.

[0168] For example, in the first abnormal event record, the dump data record is a link of "Complete Dump Data 01". The developer can click the link to open the dump data of the abnormal event. The event name of the abnormal event record is "panic", indicating that the abnormal event is a panic event. The event cause of the abnormal event record is "modem crash reset", indicating that the event cause of the abnormal event is that the modem crash triggered the subsystem reset.

[0169] For the abnormal events occurring in the subsystems recorded by the second cloud device, some of the abnormal events occurring in the subsystems can be located by the SSR dump data recorded in the second cloud device. In this case, the second cloud device only needs to provide the SSR dump data to the developer.

[0170] There are some abnormal events that occur in some subsystems that are difficult to locate through the SSR dump data recorded in the second cloud device. In this case, the second cloud device can push the abnormal events that are difficult to locate through the SSR dump data to the first cloud device. For example, the second cloud device can send event information of abnormal events that are difficult to locate through SSR dump data to the first cloud device. The first cloud device can generate the above-mentioned configuration file based on the event information of the abnormal event sent by the second cloud device, and send the configuration file to the mobile phone, so that when the abnormal event recorded in the configuration file occurs, the mobile phone generates complete dump data of the abnormal event.

[0171] The method provided by the embodiment of the present application is further illustrated by an example below. Fig.11 As shown, the mobile phone includes an application processor subsystem APSS and multiple additional subsystems. The application processor subsystem can be a subsystem run by the application processor. The multiple additional subsystems include additional subsystems run by additional processors such as modem, Wi-Fi, ADSP, CDSP, etc. The application processor subsystem of the mobile phone includes a local service layer and a kernel layer.

[0172] The first cloud device sends a push message to the mobile phone. The cloud push configuration service in the mobile phone receives the push message sent by the first cloud device. The cloud push configuration service can be a cloud push configuration service of a big data service in the mobile phone. The cloud push configuration service can obtain the configuration file for the event cause that needs to provide complete dump data through the push message, and send a configuration message to the subsystem log service, and notify the subsystem log service of the received configuration file through the configuration message. The subsystem log service further writes the configuration file to a preset configuration node of the system file in the memory to save the configuration file.

[0173] Take the first abnormal event occurring in the modem of the multiple additional subsystems of the mobile phone as an example. When the first abnormal event occurs in the modem, the modem can send an SSR interrupt message of the first abnormal event to the application processor subsystem. The kernel layer of the application processor subsystem includes an SSR driver. The application processor subsystem receives the SSR interrupt message triggered by the first abnormal event of the modem through the communication interface in the SSR driver.

[0174] The SSR driver of the application processor subsystem also includes a subsystem failure log module. After the SSR driver of the application processor subsystem receives the SSR interrupt message triggered by the first abnormal event through the communication interface, the event information of the first abnormal event can be obtained through the interrupt function, and the event information of the first abnormal event can be transmitted to the subsystem failure log module.

[0175] After receiving the event information of the first abnormal event, the subsystem failure log module can match the event information of the first abnormal event with the configuration file in the preset configuration node to determine whether the event information of the first abnormal event matches at least one configuration record in the pre-stored configuration file.

[0176] If the event information of the first abnormal event matches at least one configuration record in the configuration file, the subsystem failure log module writes the event information of the first abnormal event into the failure log as the event information of the panic event, triggers the panic event, and generates complete dump data. In this way, in the case where the first abnormal event is an abnormal event that is difficult to locate through the SSR dump data, the mobile phone can convert the first abnormal event occurring in the additional subsystem modem into a panic event occurring in the application processor subsystem, and generate complete dump data including the modem memory mirror data and the application processor subsystem memory mirror data.

[0177] If the event information of the first abnormal event does not match any configuration record in the configuration file, the subsystem failure log module adds the work task of the first abnormal event to the preset work queue (workqueue) of asynchronous processing, asynchronously generates the SSR dump data of the modem, and records the SSR dump data and event information of the first abnormal event in the dump node and reason node of the shared memory respectively. In this way, if the first abnormal event is an abnormal event that can be located by the SSR dump data, the mobile phone can generate SSR dump data including the modem memory mirror data.

[0178] In some other embodiments of the present application, the first cloud device may also send a deletion configuration instruction to the mobile phone. The deletion configuration instruction is used to instruct the mobile phone to clear the configuration file saved in the preset configuration node. After receiving the deletion configuration instruction sent by the first cloud device, the mobile phone may delete the configuration file saved in the preset configuration node. The additional subsystem of the mobile phone only generates SSR dump data after an abnormal event occurs. In this way, developers can use the first cloud device to choose whether the mobile phone generates a complete dump data triggered by the additional subsystem, which facilitates the system debugging of the mobile phone for developers.

[0179] Some other embodiments of the present application provide an electronic device, which includes: a memory and one or more processors. The memory is coupled to the processor. The processor can run an application processor subsystem and multiple additional subsystems. The memory stores a computer program code, which includes computer instructions. When the computer instructions are executed by the processor, the electronic device can perform various functions or steps in the above method embodiments.

[0180] In an implementation of this embodiment, the electronic device further includes a communication module. The communication module is coupled to the processor. The communication module is used to transmit data or signaling with the first cloud device or the second cloud device.

[0181] Of course, the electronic device may also include other hardware structures such as other antennas for receiving signals. For example, the electronic device also includes hardware structures such as cameras and display screens. The structure of the electronic device can refer to Figure 2 The structure of the mobile phone 100 is shown.

[0182] The embodiment of the present application also provides a chip system, which is applied to an electronic device. The chip system includes at least one processor and at least one interface circuit. The processor and the interface circuit can be interconnected by lines. For example, the interface circuit can be used to receive signals from other devices (such as memory). For another example, the interface circuit can be used to send signals to other devices (such as processors). Exemplarily, the interface circuit can read instructions stored in the memory and send the instructions to the processor. When the instruction is executed by the processor, the electronic device can perform the various steps in the above embodiments. Of course, the chip system can also include other discrete devices, which are not specifically limited in the embodiment of the present application.

[0183] An embodiment of the present application also provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device, the electronic device executes each function or step in the above-mentioned method embodiment.

[0184] The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, the computer is enabled to execute each function or step in the above method embodiment.

[0185] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0186] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0187] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0188] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0189] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0190] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for generating dump data, It is characterized in that Applied to an electronic device, the electronic device includes an application processor subsystem and a plurality of additional subsystems; the method includes: Receive a subsystem restart SSR interrupt message; wherein the SSR interrupt message is triggered by a first abnormal event occurring in a target subsystem among the multiple additional subsystems; In response to the SSR interrupt message, acquiring event information of the first abnormal event; wherein the event information includes an event cause and a subsystem type, the event cause is used to indicate the abnormal cause reported by the target subsystem, and the subsystem type is used to characterize the subsystem in which the first abnormal event occurs; Determine whether the event information of the first abnormal event matches at least one configuration record of a pre-stored configuration file; wherein the configuration file is received when the input information meets a preset configuration condition, the preset configuration condition includes that the abnormal event indicated by the input information belongs to an abnormal event that cannot be located through SSR dump data, and the configuration record is used to indicate an abnormal event that provides complete dump data; If the event information of the first abnormal event matches at least one configuration record of the configuration file, complete dump data is generated, and the configuration record matching the event information of the first abnormal event is deleted from the configuration file; wherein the complete dump data includes memory mirror data of the application processor subsystem and memory mirror data of the target subsystem.

2. The method according to claim 1, It is characterized in that If the event information of the first abnormal event matches at least one configuration record of the configuration file, generating complete dump data includes: If the event information of the first abnormal event matches at least one configuration record of the configuration file, a panic event at the operating system level is triggered to generate the complete dump data.

3. The method according to claim 2, It is characterized in that Before triggering the panic event, the method further includes: The event information of the first abnormal event is recorded as the event information of the panic event.

4. The method according to any one of claims 1 to 3, It is characterized in that The method further comprises: In response to the SSR interrupt message, shielding other interrupt requests; The generating of complete dump data includes: The complete dump data is generated while other interrupt requests are masked.

5. The method according to any one of claims 1 to 3, It is characterized in that The generating of complete dump data includes: The memory data of the application processor subsystem and the memory data of the target subsystem are copied to generate the complete dump data.

6. The method according to any one of claims 1 to 3, It is characterized in that The method further comprises: If the event information of the first abnormal event does not match any configuration record of the configuration file, SSR dump data is generated; wherein the SSR dump data includes memory mirror data of the target subsystem.

7. The method according to claim 6, It is characterized in that If the event information of the first abnormal event does not match any configuration record of the configuration file, generating SSR dump data includes: Adding a work task for the first abnormal event to a preset work queue; Asynchronously process the work task of the first abnormal event in the preset work queue to generate the SSR dump data.

8. The method according to any one of claims 1 to 3, It is characterized in that Before receiving the subsystem restart SSR interrupt message, it also includes: Receiving a push message sent by the first cloud device; wherein the push message carries the configuration file or the acquisition path of the configuration file; In response to the push message, the configuration file is read and written into a memory.

9. The method according to any one of claims 1 to 3, It is characterized in that The method further comprises: Report the first abnormal event to a second cloud device; wherein the second cloud device is used to count abnormal events of the electronic device.

10. The method according to any one of claims 1 to 3, It is characterized in that The plurality of additional subsystems include a subsystem executed by at least one additional processor of a modem, a Wi-Fi, an audio digital signal processor, and a computing digital signal processor.

11. An electronic device, It is characterized in that include: A memory and one or more processors; the memory is coupled to the processor; The processor runs an application processor subsystem and multiple additional subsystems; wherein the memory stores computer program code, the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the method as described in any one of claims 1-10.

12. A computer-readable storage medium, It is characterized in that The method comprises computer instructions, and when the computer instructions are executed on an electronic device, the electronic device executes the method as claimed in any one of claims 1 to 10.

Images