CN116450225A

CN116450225A - Log generation method and electronic equipment

Info

Publication number: CN116450225A
Application number: CN202210018489.XA
Authority: CN
Inventors: 余亮; 郭晓杰; 赵俊民
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-01-07
Filing date: 2022-01-07
Publication date: 2023-07-18

Abstract

The application provides a log generation method and electronic equipment, wherein the method comprises the following steps: under the condition that the electronic equipment fails, acquiring a first original log related to the failure and acquiring a process identifier related to the failure; acquiring a first call chain based on the process identifier, wherein the first call chain comprises a binder chain and a lock chain; and adding the first call chain to the first original log to obtain a first target log. According to the method and the system, when the electronic equipment is detected to be faulty, the call chain related to the faulty process is added to the original log to obtain the target log, so that a developer can more quickly and effectively solve the fault through the target log added with the call chain.

Description

Log generation method and electronic equipment

Technical Field

The embodiment of the application relates to the field of terminal equipment, in particular to a log generation method and electronic equipment.

Background

With the popularization and development of electronic devices, electronic devices having touch screens are increasingly entering people's lives. In the using process of the existing electronic equipment, the electronic equipment can be failed due to abnormal operation of some key processes, so that the electronic equipment has the problems of no response of application or no response of system service and the like. When the fault of the electronic equipment is detected, the fault location can be performed through the related log information. Therefore, how to obtain more accurate log information is a technical problem to be solved.

Disclosure of Invention

In order to solve the technical problems, the application provides a log generation method and electronic equipment. In the method, if the electronic equipment is detected to be faulty, a call chain related to a faulty process is added to an original log to obtain a target log. Therefore, the developer can more quickly and effectively solve the faults through the target log added with the call chain.

In a first aspect, an embodiment of the present application provides a log generating method. The method comprises the following steps: under the condition that the electronic equipment fails, acquiring a first original log related to the failure and acquiring a process identifier related to the failure; acquiring a first call chain based on the process identifier, wherein the first call chain comprises a binder chain and a lock chain; and adding the first call chain to the first original log to obtain a first target log. Thus, the developer can quickly and effectively position the fault by combining the binder chain and the lock chain.

According to a first aspect, obtaining a process identification associated with a failure includes: if the fault is the application non-response, the main process identification corresponding to the abnormal application program is obtained, and the main process identification is used as the fault related process identification. In this way, the call chain associated with the host process may be obtained when an application non-responsive exception occurs at the electronic device.

According to the first aspect, or any implementation manner of the first aspect, after obtaining the first target log, the method includes: the corresponding process is identified by the killing master process. Therefore, the call chain can be obtained, so that a developer can conveniently locate faults, and recovery of the fault application program can be tried to ensure the use experience of a user.

According to the first aspect, or any implementation manner of the first aspect, the obtaining a process identifier related to the fault includes: if the fault is abnormal in the system watchdog, the identification of the system service process is obtained, and the identification of the system service process is used as the process identification related to the fault. In this way, call chains associated with system services may be obtained when a system watchdog exception occurs at an electronic device.

According to the first aspect, or any implementation manner of the first aspect, after obtaining the first target log, the method includes: determining whether a deadlock event occurs to a system service process based on a lock chain; if the system service process generates a deadlock event, determining an opposite end process of the system service process based on the binder chain, and killing the opposite end process. Therefore, not only can the call chain associated with the system service process be obtained so as to facilitate the positioning of the faults by the developer, but also the recovery of the system service process can be tried to ensure the use experience of the user.

According to the first aspect, or any implementation manner of the first aspect, after killing the peer process, the method includes: if the electronic equipment does not recover to normal operation, a second call chain is acquired, and a second original log related to the fault is acquired; and adding the second call chain to the second original log to obtain a second target log. Thus, the electronic equipment can acquire the latest target log, so that a developer can more accurately position the fault.

According to the first aspect, or any implementation manner of the first aspect, after obtaining the second target log, the method includes: killing the system service process. Therefore, the electronic equipment automatically restarts the system, and the use experience of the user can be ensured to a certain extent.

According to the first aspect, or any implementation manner of the first aspect, a call depth of a process in a binder chain is 3 layers.

In a second aspect, embodiments of the present application provide an electronic device. The electronic device includes: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored on the memory, which when executed by the one or more processors, cause the electronic device to perform the steps of: under the condition that the electronic equipment fails, acquiring a first original log related to the failure and acquiring a process identifier related to the failure; acquiring a first call chain based on the process identifier, wherein the first call chain comprises a binder chain and a lock chain; and adding the first call chain to the first original log to obtain a first target log.

According to a second aspect, the computer program, when executed by one or more processors, causes the electronic device to perform the steps of: if the fault is the application non-response, the main process identification corresponding to the abnormal application program is obtained, and the main process identification is used as the fault related process identification.

According to a second aspect, or any implementation of the second aspect above, the computer program, when executed by one or more processors, causes the electronic device to perform the steps of: the corresponding process is identified by the killing master process.

According to a second aspect, or any implementation of the second aspect above, the computer program, when executed by one or more processors, causes the electronic device to perform the steps of: if the fault is abnormal in the system watchdog, the identification of the system service process is obtained, and the identification of the system service process is used as the process identification related to the fault.

According to a second aspect, or any implementation of the second aspect above, the computer program, when executed by one or more processors, causes the electronic device to perform the steps of: determining whether a deadlock event occurs to a system service process based on a lock chain; if the system service process generates a deadlock event, determining an opposite end process of the system service process based on the binder chain, and killing the opposite end process.

According to a second aspect, or any implementation of the second aspect above, the computer program, when executed by one or more processors, causes the electronic device to perform the steps of: if the electronic equipment does not recover to normal operation, a second call chain is acquired, and a second original log related to the fault is acquired; and adding the second call chain to the second original log to obtain a second target log.

According to a second aspect, or any implementation of the second aspect above, the computer program, when executed by one or more processors, causes the electronic device to perform the steps of: killing the system service process.

According to a second aspect, or any implementation manner of the second aspect, the call depth of a process in a binder chain is 3 layers.

In a third aspect, embodiments of the present application provide a chip. The chip includes one or more interface circuits and one or more processors; the interface circuit is used for receiving signals from the memory of the electronic device and sending signals to the processor, wherein the signals comprise computer instructions stored in the memory; the computer instructions, when executed by a processor, cause an electronic device to perform the method of fault detection of any of the first aspect and the second aspect.

Any implementation manner of the third aspect and any implementation manner of the third aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. The technical effects corresponding to the third aspect and any implementation manner of the third aspect may be referred to the technical effects corresponding to the first aspect and any implementation manner of the first aspect, which are not described herein.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium. The computer readable storage medium comprises a computer program, characterized in that the computer program, when run on an electronic device, causes the electronic device to perform the first aspect and any one of the fault detection methods of the first aspect.

Any implementation manner of the fourth aspect and any implementation manner of the fourth aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. Technical effects corresponding to any implementation manner of the fourth aspect may be referred to the technical effects corresponding to any implementation manner of the first aspect, and are not described herein.

Drawings

Fig. 1 is a schematic view of an application scenario provided in an embodiment of the present application;

Fig. 2 is a schematic display diagram of an interface when an application unresponsive exception occurs in an electronic device according to an embodiment of the present application;

fig. 3 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

fig. 4 is a schematic software structure of an electronic device according to an embodiment of the present application;

FIG. 5 is a schematic flow chart of a log generating method according to an embodiment of the present application;

fig. 6 is a schematic frame diagram of a log generating method according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a call chain in a log generation method according to an embodiment of the present application;

FIG. 8 is a schematic flow chart of a log generation method according to another embodiment of the present application;

FIG. 9 is a schematic flow chart of a log generation method according to another embodiment of the present application;

fig. 10 is a schematic diagram of a lock chain corresponding to a deadlock in a log generation method according to another embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that in embodiments of the present application, "one or more" means one, two, or more than two; "and/or", describes an association relationship of the association object, indicating that three relationships may exist; for example, a and/or B may represent: a alone, a and B together, and B alone, wherein A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship.

The terms first and second and the like in the description and in the claims of embodiments of the present application are used for distinguishing between different objects and not necessarily for describing a particular sequential order of objects. For example, the first target object and the second target object, etc., are used to distinguish between different target objects, and are not used to describe a particular order of target objects.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

In the description of the embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" means two or more. For example, the plurality of processing units refers to two or more processing units; the plurality of systems means two or more systems.

Before describing the methods in the embodiments of the present application, in order to facilitate understanding of the embodiments of the present application by those skilled in the art, related concepts related to the embodiments of the present application are described.

1) Progress of a process

A process (process) is a running activity of an application program on a certain data set, and is a basic unit of resource allocation and scheduling by an operating system (e.g., an Android system). Each process occupies a memory space, and the application program runs on the operating system in the form of one or more processes to realize corresponding functions.

2) Thread(s)

A thread (thread) is an entity of a process that is a smaller unit of independence running than a process. A thread may share all of the resources owned by a process with other threads that belong to the same process. One thread may create and revoke another thread, and multiple threads in the same process may execute in parallel.

3) Object lock

Object locks are a mechanism that ensures that only one thread accesses a certain method or variable at a time. In Java or other object-oriented languages, when a thread accesses synchronized code, the object lock to which the code belongs must be acquired, otherwise the thread will block until the object lock is released.

An object lock is a mutex lock, i.e., at most one thread can acquire the lock, when thread a attempts to acquire the object lock held by thread B, thread a must wait or block until thread B releases the lock before thread a can acquire the object lock to access the corresponding method or variable.

4) Thread blocking

Thread blocking generally refers to a timeout phenomenon caused by a thread having a time-out period greater than a predetermined value during execution. For example, in the execution process of the thread a, the execution result of the thread B needs to be used as an input parameter to continue the execution, so that if the thread a does not obtain the execution result of the thread B, the execution is paused, and if the thread a does not obtain the execution result of the thread B later in a preset time, the thread a is blocked.

5)ANR

ANR (Application Not Responding), application unresponsiveness), means that when a specific function is performed, the display interface of the electronic device is delayed, and a frame loss phenomenon occurs.

Specifically, ANR refers to an application program executing in response to a user operation exceeding a threshold preset by the electronic device. The preset threshold value refers to preset time for processing a single event by the electronic device. In most cases, the application will return to normal by itself after a brief period of time. If the application continues to remain stuck after a short period of time, this will cause a higher level of warning, resulting in the user's operation not being successfully performed.

6)watchdog

The watchdog is a piece of software running in the Android platform and used for monitoring a system_server (system service process). System_server is the most important process in Android platform, and most of the services in the whole platform are run inside. Near 50 threads are running in the system_server process, and any thread stuck may cause the entire system to be stuck.

The watchdog is used for monitoring system services running in a system service process and grabbing stack information under the condition that the system watchdog is abnormal. In addition, the watchdog restarts the system service if it monitors for system watchdog anomalies and does not automatically recover within a specified time.

7)system_sever

The system_server is the core of the Android system, is a Android framework-layer system service module, has the main function of managing system services for Android application development, and starts initialization and operation immediately after the Dalvik virtual machine is started, and other system services operate in the environment of the system_server process.

8)IPC

Inter-process communication (IPC, inter-Process Communication) refers to some technique or method of transferring data or signals between at least two processes or threads. IPC is mainly used for message passing between different processes in a computer system.

The process is the minimum unit of computer resource allocation, each process has its own virtual address space and is isolated from the virtual address spaces of other processes, that is, one process can only access its own virtual address space and cannot access the virtual address spaces of other processes. In order to enable different processes to access and coordinate work with each other, operating systems provide a variety of IPC mechanisms. For example, a binder mechanism.

9)binder

The binder is a mode of interprocess communication in the Android system and is also one of the most important characteristics in the Android system. Android includes four major components, namely Activity (workflow), service (Service), broadcast (Broadcast receiver) and content provider (content provider), and different applications and the like all run in different processes, and a binder is a bridge for communication between the processes. Just as the name "adhesive" is, the binder bonds the components of the system together and is the bridge for the components.

The binder adopts a C/S architecture, which may include clients, servers, serviceManager, and a binder driver, where the ServiceManager is used to manage various services in the system.

The Client process is a process using the service, the Server process is a process providing the service, and the ServiceManager process is used for converting a name of a binder in a character form into a reference to the binder in the Client, so that the Client can obtain the reference to a binder entity in the Server through the binder. The binder driver is responsible for a series of underlying support such as establishment of binder communication between processes, transfer of binders between processes, binder reference count management, transfer and interaction of data packets between processes, etc.

Please refer to fig. 1, which is an exemplary diagram of an application scenario provided in an embodiment of the present application. As shown in fig. 1, when a user performs an operation on the electronic device 100, the electronic device 100 generates a target log, and then the electronic device 100 may upload the generated log to a cloud (server) through a communication network. On this basis, the developer can acquire the log of the electronic device 100 from the cloud (server) through the terminal device 200. By analyzing the target log, a developer can determine the cause of the fault.

In addition, the electronic device 100 and the terminal device 200 may be directly connected through a development tool, that is, the terminal device 200 obtains log information of the electronic device 100 through the development tool, and analyzes the log information on the basis of the log information to obtain a failure cause.

In the running process of an application program in the electronic equipment, if the application program cannot respond to touch operation of a user within a certain time, the electronic equipment is indicated that an application program unresponsiveness Abnormality (ANR) possibly occurs. At this time, a prompt box as shown in fig. 2 may be popped up on the display interface of the electronic device, and the user is informed of the abnormal condition that the application program a has no response in the running process through the prompt box. If the user clicks the "close application" control, the electronic device forcibly closes the main process of application A and records a fault-related log.

In addition, if the system service of the electronic device cannot respond to the touch operation of the user within a certain time in the running process, the problem that the electronic device possibly has abnormal system watchdog is indicated. The problem of system watchdog anomalies can be monitored by means of a watchdog.

When the electronic equipment generates an application unresponsive exception or a system server unresponsive exception, a log related to the fault is recorded, however, the log recorded at this time only contains information related to the main process, and a developer cannot quickly locate the position of the fault through the log. Thus, the resolution of the fault by the developer is greatly affected.

Therefore, in order to quickly and effectively locate the fault location, when determining that the electronic device has a fault, the embodiment of the application can determine the fault-related process. On the basis, a call chain related to the process is acquired, and the call chain is added to an original log to obtain a target log. Therefore, the developer can more quickly and effectively solve the faults through the target log added with the call chain.

The log generating method in the embodiment of the present application may be applied to an electronic device shown in fig. 3, where the electronic device 100 shown in fig. 3 may be a terminal, and the terminal may be a cellular phone (cellular phone), a tablet computer (pad), a wearable device, or a device with a camera such as an internet of things device, which is not limited in this application. It should be noted that the schematic structural diagram of the electronic device 100 may be applied to the electronic device in fig. 2.

It is further noted that the electronic device 100 may have more or fewer components than shown in the figures, may combine two or more components, or may have a different configuration of components. The various components shown in fig. 3 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.

The electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal Serial Bus (USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset interface 170D, sensor module 180, keys 190, motor 191, indicator 192, camera 193, display 194, and Subscriber Identity Module (SIM) interface 195, etc. The sensor module 180 may include a pressure sensor, a gyroscope sensor, a barometric sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

It should be understood that the illustrated structure of the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processor (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 Processor (NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and a command center of the electronic device 100, among others. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a MiniUSB interface, a micro USB interface, a USB type c interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transfer data between the electronic device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other electronic devices, such as AR devices, etc.

The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charge management module 140 may receive a charging input of a wired charger through the USB interface 130. In some wireless charging embodiments, the charge management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, the wireless communication module 160, and the like. The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The wireless communication module 160 may provide solutions for wireless communication including Wireless Local Area Networks (WLANs) such as wireless fidelity (Wi-Fi) networks, bluetooth (BT), global Navigation Satellite Systems (GNSS), frequency Modulation (FM), near Field Communication (NFC), infrared (IR), and the like, applied to the electronic device 100.

In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques.

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a Liquid Crystal Display (LCD) and an organic light-emitting diode (OLED). In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, electronic device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

The external memory interface 120 may be used to connect an external memory card, such as a MicroSD card, to enable expansion of the memory capabilities of the electronic device 100. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card.

The internal memory 121 may be used to store computer executable program code including instructions. The processor 110 executes various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121. The internal memory 121 may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like.

The electronic device 100 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110.

Touch sensors, also known as "touch panels". The touch sensor may be disposed on the display screen 194, and the touch sensor and the display screen 194 form a touch screen, which is also referred to as a "touch screen". The touch sensor is used to detect a touch operation acting on or near it. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor may also be disposed on a surface of the electronic device 100 at a different location than the display 194.

The keys 190 include a power-on key (or power key), a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100. The mobile phone can be turned off or turned on by pressing the power key. And when the duration of pressing the power key exceeds a certain duration, the electronic device 100 may enter a restart state.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback. For example, touch operations acting on different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The layered architecture of the electronic device 100 divides the software into several layers, each with a distinct role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into three layers, an application layer, an application framework layer, and a kernel layer from top to bottom.

The application layer may include a series of application packages.

As shown in fig. 4, the application layer may include applications for cameras, gallery, calendar, phone calls, maps, WLAN, bluetooth, music, video, short messages, etc. The application framework layer provides an Application Programming Interface (API) and a programming framework for the application of the application layer. The application framework layer includes a number of predefined functions. As shown in fig. 4, the application framework layer may include a window manager, a content provider, a view system, a telephony manager, a resource manager, a notification manager, and the like. Wherein the window manager may run in the system_server mentioned above.

The kernel layer is a layer between the hardware and the software layers described above. The kernel layer at least comprises a power key driver, a display driver, a fault detection module, a fault processing module, a log generation module and the like. The hardware may include a camera, a display screen, a microphone, a processor, a memory, and the like.

The fault detection module is used for determining whether the electronic equipment is faulty, and if the electronic equipment is faulty, the fault detection module can be used for acquiring a process identifier related to the fault. In addition, the fault detection module can also be used for determining whether the electronic equipment is recovered to normal operation.

The log generation module is used for acquiring a call chain related to the fault process and adding information of the call chain into the original log to obtain a target log.

The fault processing module is used for correspondingly adopting different fault processing operations when different types of anomalies occur to the electronic equipment. For example, the failure handling module may kill the main process of the failed application when an application non-responsive exception occurs to the electronic device.

It will be appreciated that the layers and components contained in the layers in the software structure shown in fig. 4 do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer layers than shown, and more or fewer components may be included in each layer, as the present application is not limited.

In the embodiment of the application, under the condition that the electronic equipment is determined to be faulty, a fault-related process can be determined. On the basis, a call chain corresponding to the process is obtained, and the call chain is added to the original log to obtain the target log. Therefore, the developer can quickly locate the position where the fault happens by using the log added with the call chain, and further the fault solving speed is increased.

As shown in fig. 5, a log generating method provided in an embodiment of the present application may include steps S110 to S140 described below.

Step S110: the fault detection module determines whether the electronic device is faulty.

In the embodiment of the application, the fault generated by the electronic device may be an application unresponsive exception (ANR) generated by the electronic device, or a system watchdog exception (vmwatch) generated by the electronic device. The application non-response exception may be caused by a blockage of a main process of an application program running by the electronic device, or caused by a blockage sent by a certain thread in the main process.

In addition, the system watchdog exception may also be referred to as a system service unresponsive exception, which may be caused by a system service process of the electronic device blocking during operation, that is, a certain thread in the system service process blocking to cause the electronic device to generate the system service unresponsive exception. Thus, the failure of the electronic device in embodiments of the present application may be caused by thread blocking.

As one way, the fault detection module may detect whether the electronic device has a fault, and if it is detected that the electronic device has a fault, the fault detection module may obtain a process identifier related to the fault, i.e. go to step S120. In addition, if the failure detection module does not detect that the electronic device fails, the failure detection operation may be continued.

In some embodiments, the fault detection module may obtain current operating parameters of the electronic device when determining whether the electronic device is faulty. In general, the operation parameters are directly reflected in the operation condition of the electronic equipment, so that the embodiment of the application can determine whether the electronic equipment fails or not through the operation parameters of the electronic equipment, and the accuracy of failure detection can be ensured.

In other embodiments, the fault detection module determines whether the electronic device is malfunctioning, either by determining whether an application-unresponsive exception has occurred to the electronic device, or by determining whether a system watchdog exception has occurred to the electronic device.

In one mode, when the fault detection module determines whether the electronic device generates the application non-response abnormality/the system watchdog abnormality, an identifier corresponding to the application non-response abnormality/the system watchdog abnormality can be obtained, and whether the electronic device fails is determined based on the identifier.

Specifically, the fault detection module may determine whether the identifier corresponding to the application non-response exception/system watchdog exception is a specified identifier, and if the identifier corresponding to the application non-response exception/system watchdog exception is the specified identifier, determine that the application non-response exception/system watchdog exception occurs in the electronic device.

In the embodiment of the application, the identification corresponding to the unresponsive exception/system watchdog exception is mainly used for representing whether the electronic equipment generates the corresponding exception. As one example, the identifier corresponding to the application non-response exception is a, and if a is 1, it is characterized that the electronic device generates the application non-response exception. In addition, if A is 0, the electronic equipment is characterized as not generating application non-response abnormality.

As another example, the identification corresponding to the system watchdog exception is W, and if B is 1, it is indicative that the electronic device generates the system watchdog exception. In addition, if W is 0, the electronic equipment is characterized that the system watchdog abnormality does not occur.

It should be noted that the specific identifier may be other values, specifically, which value is not explicitly limited herein, so long as it can clearly distinguish whether an application unresponsive exception/a system watchdog exception occurs.

In another way, when the fault detection module determines whether the electronic device generates the application unresponsive exception, the fault detection module may also acquire the waiting time of the application process, and when the waiting time of the application process exceeds the first specified duration, determine that the electronic device generates the application unresponsive exception. The first specified duration may be 5s.

In another way, the fault detection module may also obtain a waiting time of the system service process when determining whether the electronic device is abnormal in the system watchdog, and determine that the electronic device is abnormal in the system watchdog when the waiting time exceeds a second specified duration. Wherein the second specified duration may be 30s.

Step S120: the fault detection module obtains a fault-related process identifier.

As one way, when determining that the electronic device fails, the failure detection module may obtain a process identifier related to the failure, that is, determine a process that causes the failure to occur.

From the above description, it is known that a process/thread is blocked, which usually causes the electronic device to malfunction, i.e. to get stuck. Therefore, when determining that the electronic device has a fault, the embodiment of the application can acquire the process causing the fault, namely, acquire the process identifier related to the fault.

In the embodiment of the present application, the process identifier related to the failure may be a main process identifier. For example, when the electronic device runs the application program 1, an application unresponsive exception occurs, and at this time, the failure detection module may determine the main process a of the application program 1, and use the identity of the main process a as the failure-related process identity.

In addition, the fault detection module may also obtain a thread identifier when obtaining a process identifier related to the fault, where the thread identifier may be an identifier of a certain thread in the main thread. The failure of the electronic device may be caused by the blocking of a certain thread in the main process, and the failure location can be more quickly and effectively located by acquiring the thread identification.

Step S130: the fault detection module sends the process identification to the log generation module.

In some embodiments, when the fault detection module obtains the process identifier related to the fault, it may send the process identifier to the log generation module, and the log generation module may obtain the call chain based on the process identifier, that is, go to step S130.

It should be noted that, the process identifier sent by the fault detection module may include, in addition to the process identifier, the identifier of the thread in the process.

Step S140: the log generation module acquires a call chain based on the process identifier, and adds the call chain to the original log to obtain a target log.

As one way, when the log generation module obtains the process identifier, it may obtain a call chain associated with the process identifier, and then add the call chain to the original log to obtain the target log.

In the embodiment of the application, the call chain associated with the process identifier may include a binder chain and a lock chain, where the binder chain may be formed by call relationships between processes. In other words, a binder chain may be a call relationship that results from each process performing inter-process communication.

In addition, the lock chain may be composed of the relationships of object locks corresponding to threads in a process. The object lock may be a mutex lock, that is, at most one thread in a process can acquire the target lock.

As one approach, a chain of bonders may also be referred to as a chain of bonders calls, the chain of bonders calls comprising at least one process, and the at least one process comprising at least one thread. When the binder call chain includes more than two processes, the call chain includes at least cross-process calls and cross-thread calls.

In some embodiments, when the log generating module obtains the binder call chain based on the process identifier, the log generating module may first use the process corresponding to the process identifier as the first node, and then find whether a preset call chain is cached in the call chain using the first node as the starting node.

The call chain cache is used for storing call chains, the binder call chain represents a directed graph of call relations among nodes, one binder call chain at least comprises a starting node and a terminating node, the starting node represents the first node of the call chain, and the terminating node represents the last node of the call chain. For example, the form of a binder call chain is: a, B and C are as follows: node a calls node B first and then node B calls node C.

For a better understanding of the call chain, an example diagram is presented in fig. 6. As can be seen from FIG. 6, process A calls process B and process B calls process C, and the call relationship between these processes may form a binder chain. Wherein the binder chain can be expressed as: process a→process b→process C. Wherein process a may be an application process, process B may be a service process, and process C may be a HAL (Hardware Abstraction Layer ) process.

It should be noted that the call depth of the process in the binder chain is configurable. As one way, the call depth of a process in the binder chain may be 3.

In addition, when the process a calls the process B, it may be implemented by calling a certain thread in the process B. As shown in fig. 6, process a makes a call by calling Thread1 (Thread 1) in process B. In addition, when the process B is called, the Thread1 (Thread 1) in the process B needs to acquire the lock 1 to execute the corresponding task, and the lock 1 is held by the Thread2 (Thread 1), so the Thread1 (Thread 1) is in the lock waiting state. In addition, process B invokes process C through Thread2 (Thread 2).

In some embodiments, call relationships between threads in the same process form a lock chain. For example, the lock chain may be T1→T2, meaning that the lock that thread T1 waits for is being held by thread T2.

As one way, the log generation module may include an indexer of a lock, through which the embodiment of the present application may obtain a thread holding the lock, and thus obtain a lock chain. The indexer of the lock may be a bidirectional indexer, i.e. the associated thread identity may be indexed by the identity of the lock. In addition, the identity of the associated lock may also be indexed by the identity of the thread.

In this embodiment of the present application, each process corresponds to a unique process identifier, and each thread in each process also corresponds to a unique thread identifier. In addition, each lock may also have a unique lock identification. Wherein bidirectional indexing can be performed between threads and locks.

Specifically, each thread may have a plurality of locks, where the plurality of locks may include a lock held by the thread and a lock waiting for the thread, where the lock waiting for the thread may know which threads hold the lock waiting for the target thread, and the lock waiting for the target thread may know which threads are waiting for the lock held by the target thread. In addition, in lock chains

As one example, thread 1 corresponds to lock 1, lock 2, and lock 3. Lock 1 is the lock that thread 1 waits on, and locks 2 and 3 are the locks that thread 1 holds. It can be seen that thread 1 is waiting for lock 1 to be held by thread 4, and that thread 1 is only able to perform the corresponding task if thread 4 releases lock 1.

In addition, since bidirectional indexes can be performed between the thread and the lock, other threads waiting for the lock can be determined by the lock held by the thread 1 in the embodiment of the application. For example, thread 4 holds lock 1 and lock 4, the thread waiting for lock 1 is thread 1, and the thread waiting for lock 4 is thread 5. In summary, lock chains may be obtained by bi-directionally indexing threads and locks according to embodiments of the present application.

As one example, at least two threads in the same process compete for the same object lock,

for a better understanding of the call chain, the present embodiment gives an example diagram as shown in fig. 7. The binder chain can be obtained by the embodiment 101 in fig. 7. In addition, a lock chain may be obtained by 102 an embodiment of the present application. "From" in fig. 7 indicates a calling process, and "Dest" indicates a called process. Illustratively, the process that invokes the process in FIG. 7 is identified as "2231".

As one way, one process may have a calling relationship with multiple threads in another process. For example, the 4 th thread of process "2231" in FIG. 7 may call the 2 nd thread of process "1132". As another example, the 3 rd thread of process "2231" may call the 5 th thread of process "1132".

102 as shown in fig. 7 represents the call relationship, i.e., lock chain, between threads in the same process. Where Tid may be the identity of different threads in the same process. Tid:1 may be the identity of the first thread in process 2231; tid:2 may be the identity of the second thread in process 2231; tid:3 may be the identity of the third thread in process 2231; tid:4 may be the identity of the fourth thread in process 2231.

As will be appreciated from the above description, the host process in fig. 7 may be a System service process (System server), identified as "2231". As seen in fig. 7, thread 1 "tid" in the system service process: 1 "is in the blocked state and its waiting lock is represented by thread 4" tid: 4'. In addition, it is seen from FIG. 7 that process "2231" may be performed by thread 4"tid:4 "call thread 2 in process 1132".

In this embodiment of the present application, the binder chain and the lock chain may be pre-stored in the electronic device, and after the process identifier is obtained, the binder chain and the lock chain may be obtained correspondingly.

It should be noted that, the call chains acquired in the embodiment of the present application may be one or multiple, and the call chains may be specifically determined according to actual communication conditions between processes.

In some embodiments, the log generation module, after acquiring the call chain, may add the call chain to the original log to obtain the target log. The original log may be log information in a specified time period correspondingly acquired when the electronic device fails. The original log may be an application non-response log, a system watchdog exception log, or a long key log.

As one example, upon determining that an application non-response exception occurs to the electronic device, the log generation module may obtain an application non-response exception log (ANR log) while a call chain associated with the application non-response exception may be obtained. On this basis, a call chain is added to the application non-response exception log.

As another example, upon determining that the electronic device is experiencing a system watchdog exception, the log generation module may obtain a system watchdog exception log (watchdog log) while a call chain associated with the system watchdog exception may be obtained. On this basis, a call chain is added to the system watchdog exception log.

As another example, when it is detected that the user presses the power key for a long time, and the long time exceeds a preset time, the log generation module may acquire the long key log, and may acquire the call chain related to the long press operation. On this basis, a call chain is added to the long key log. Specifically, the system_server related binder chain and the locker chain are added to the long key log.

In summary, the application unresponsive exception log, the system watchdog exception log, or the long key log that are finally obtained in the embodiment of the present application may include a call chain. When these logs are obtained, the developer can quickly and effectively solve the faults by utilizing the call chain which is combined with the logs.

In addition, the original log may include a plurality of log blocks, each log block having a different acquisition time. For example, a log block generated at the start time of a specified period is a start log, and a log block generated at the end position of the specified period is an end log block.

In some embodiments, after the log generation module obtains the call chain corresponding to the process identifier, the log generation module may add the call chain to the original log to obtain the target log. When adding the call chain to the original log, embodiments of the present application may add the call chain to the original log at the beginning location, i.e., immediately before the call chain is added to the starting log block. In addition, the call chain may also be added to the original log at the end position, i.e., after the call chain is added to the end log block.

In other embodiments, in order to enable a developer to quickly and effectively find a call chain, after the call chain is added to an original log, the embodiment of the application may also obtain a location where the call chain is added, and then write the location to a starting location of a target log, that is, immediately before writing location information of the call chain to a log block thereof. When a developer checks the target log, the developer can quickly and effectively acquire the adding position of the call chain, so that the fault solving rate is increased.

In other embodiments, a call chain file may be newly added in the electronic device, where call relationships between different processes and lock relationships between threads in a process may be stored in the call chain file. In other words, the log generation module, after acquiring the call chain, may write the call chain into the call chain file, and form the target log from the call chain file and the original log. When analyzing the target log, a developer can directly know the relationship between each process and each thread in the process through calling the chain file, and then can quickly and effectively locate the source of the fault by combining log information.

As one way, the log generation module, after adding the call chain to the original log, obtains the target log, may send the target log to the server, so that the server may analyze the failure rate of the electronic device according to the target log.

Optionally, after the server analyzes the failure rate of the electronic device according to the target log, on one hand, the server may display the failure rate to the manufacturer, so that the manufacturer measures the quality standard of the electronic device according to the failure rate index, and may find more failures and possible operations.

On the other hand, the server can also display the failure rate to a developer, so that the developer can locate the problem that the electronic equipment fails. For example, the problems of application unresponsiveness, system service unresponsiveness, and the like, and the corresponding problems are solved, so that the product quality of the electronic device can be improved.

In other embodiments, when the log generating module obtains the target log, the target log may be sent to the server, and the server sends the target log received by the server to the developer. The developer can analyze the target log to determine the position of the fault, and correspondingly give out a solution strategy and the like. In addition, the log generation module may also directly send the target log to the developer to instruct the developer to analyze the fault.

In other embodiments, the developer may be a maintenance person at a maintenance site, who is analyzing the electronic device failure problem, may grab the target log using a maintenance feedback tool, and then analyze the cause of the application non-response/system service non-response based on the grabbed target log.

As one example, a serviceman at a service site may grasp a target log from a storage area of an electronic device through a remote desktop, a short message authentication code, and the like, and print the target key log. In addition, the maintenance site may be configured with a maintenance tool maintenance feedback tool by which maintenance personnel can quickly and effectively grasp the target log and analyze the target log.

As shown in fig. 8, another embodiment of the present application provides a log generating method, which may include steps S210 to S260 described below.

Step S210: the fault detection module determines whether an application non-responsive exception occurs with the electronic device.

It is known from the above description that the application unresponsive exception may be caused by the blocking of a main process of an application program running by the electronic device, that is, the blocking of a thread in the main process to send the application unresponsive exception occurs in the electronic device. Accordingly, in determining whether an application non-response exception occurs to the electronic device, the fault detection module may determine whether an application non-response exception occurs to the electronic device.

In one mode, the fault detection module may obtain an identifier corresponding to the application non-response abnormality, then determine whether the identifier is a specified identifier, and if so, determine that the electronic device generates the application non-response abnormality. For example, whether the identification corresponding to the application non-response abnormality is 1 is determined, and if the identification corresponding to the application non-response abnormality is 1, it is determined that the electronic device generates the application non-response abnormality. In addition, if the identification corresponding to the application non-response exception is 0, it is determined that the application non-response exception does not occur in the electronic.

In another way, the fault detection module may first obtain an application program currently running on the electronic device, then determine a process corresponding to the application program, obtain a waiting time of the process, and determine that the electronic device has an application unresponsive exception when the waiting time exceeds a first specified duration. The first specified duration may be 5s. For example, the main process of the application program a is blocked when executing the corresponding task, and the blocking time exceeds the first specified duration, at this time, the fault detection module may determine that the electronic device generates an application unresponsive exception.

In some embodiments, if the fault detection module determines that the electronic device generates an application unresponsive exception, the main process identifier corresponding to the abnormal application may be obtained, and step S220 is performed. In addition, if the failure detection module does not detect that the electronic equipment generates the application non-response abnormality, the application non-response abnormality can be continuously monitored.

Step S220: the fault detection module acquires a main process identifier corresponding to the abnormal application program.

In this embodiment of the present application, each application may correspond to a main process, and when it is determined that an application unresponsive exception occurs in the electronic device, the failure detection module may determine the application that causes the exception. And then acquiring the main process of the application program, and taking the identification of the main process as the main process identification corresponding to the abnormal application program.

Step S230: the fault detection module sends the main process identification to the log generation module.

As one way, the failure detection module, after acquiring the main process identifier, may send the main process identifier to the log generation module.

Step S240: the log generation module acquires a call chain based on the main process identification, and adds the call chain to the original log to obtain a target log.

In this embodiment of the present application, after acquiring the main process identifier, the log generating module may acquire the call chain based on the main process identifier. As is known from the above description, the call chain includes a binder chain and a lock chain, where the binder chain includes a call relationship between a main process and other processes. Lock chains may include lock relationships, i.e., hold and equal lock relationships, between threads in a process. The above embodiments of how to obtain the lock chain and the binder chain have been described in detail, and the details of the process will not be repeated here.

As one way, after the log generation module obtains the call chain based on the main process identifier, it may add the call chain to the original log to obtain the target log.

Step S250: the log generation module sends killing indication information to the fault processing module.

As one way, after the log generating module acquires the target log, the log generating module may send kill instruction information to the fault processing module to instruct the fault processing module to kill the main process, i.e. go to step S260.

The killing indication information may include an identifier of a process to be killed, and the fault processing module may kill a process corresponding to the identifier when receiving the killing indication information.

In another way, after the log generation module obtains the target log, the log generation module may instruct the electronic device to output a prompt box, and when detecting that the user inputs the instruction information of "closing the application", the log generation module may send killing instruction information to the fault processing module.

Step S260: the failure handling module kills the main process.

As one way, the failure handling module, upon receiving the kill indication information, may kill, i.e., force shut down, the application program from the host process.

As shown in fig. 9, a log generating method according to still another embodiment of the present application may include steps S301 to S314 described below.

Step S301: the fault detection module determines whether a system watchdog anomaly has occurred with the electronic device.

It is known from the above description that the system watchdog exception may be caused by a blocking of a system service process of the electronic device during operation, that is, a blocking of a certain thread in the system service process causes the electronic device to generate the system watchdog exception. Therefore, when determining whether the electronic device is abnormal in the system watchdog, the fault detection module can determine whether a blocking event occurs in the system service process, and if the blocking event occurs in the system service process, the fault detection module determines that the electronic device is abnormal in the system watchdog.

In one way, the fault detection module may first obtain a waiting time of the system service process, and determine that the electronic device generates a system watchdog exception when the waiting time exceeds a second specified duration. Wherein the second specified duration may be 30s. For example, the system service process blocks when executing the corresponding task, and the blocking time exceeds the second designated time, at which point it is determined that the electronic device has a system watchdog exception.

In some embodiments, if the fault detection module determines that the electronic device has a system watchdog exception, the process identifier related to the exception is obtained, and the process proceeds to step S302. In addition, if the fault detection module does not detect that the electronic equipment generates the system unresponsive abnormality, the system unresponsive abnormality can be continuously monitored.

Step S302: the fault detection module obtains an abnormally related process identifier.

In this embodiment of the present application, when the waiting time of the system service process exceeds the second specified duration, the fault detection module may acquire the process label related to the abnormality. In addition, the process identifier related to the exception may be a process identifier corresponding to a system service process.

Step S303: the fault detection module sends the process identification to the log generation module.

As one way, when the fault detection module obtains the process identifier related to the exception, the fault detection module may send the process identifier to the log generation module, so as to refer to the log generation module obtaining the first call chain.

Step S304: the log generation module acquires a binder chain and a lock chain of a first call chain related to the process identification, and adds the binder chain and the lock chain to a first original log to obtain a first target log.

As will be appreciated from the above description, a binder chain may include call relationships between system service processes and other processes. In addition, a process may include multiple threads, and these threads typically have lock-holding and lock-waiting scenarios, which may form a lock chain. The lock chain comprises lock relations among threads in the same process. The above embodiments of how to obtain the lock chain and the binder chain have been described in detail, and the details of the process will not be repeated here.

Step S305: the log generation module sends deadlock detection indication information to the deadlock detector.

The deadlock detection indication information is used for indicating a deadlock detector to detect whether a deadlock event occurs in a system service process. In addition, the deadlock detection indication information may carry a binder chain and a lock chain.

Step S306: the deadlock detector determines whether a deadlock event occurs to a system service process based on a lock chain.

In some embodiments, a deadlock event refers to a situation where threads in the same process are all in an equal lock state, and a closed loop equal lock is formed between threads during the equal lock process. Thus, when the deadlock detection indication information is acquired, the deadlock detector can determine whether a deadlock event occurs to a system service process based on a lock chain. For a better understanding of the lock chains corresponding to the deadlocks, the embodiment of the present application gives a diagram as shown in fig. 10.

As can be seen from fig. 10, thread 1"tid:1 "waiting lock is threaded 3" tid:3 "hold, thread 3" tid:3 "waiting lock is threaded 4" tid:4 "hold, and thread 4" tid:4 "waiting lock is written by thread 1" tid:1 "hold. It can be seen that, in fig. 10, thread 1, thread 3 and thread 4 are all in the equal lock state, and a closed loop equal lock state is formed between each thread, so that each thread cannot obtain a lock, and a deadlock event occurs.

As one way, the deadlock detector, upon determining that a deadlock event has occurred with the system service process, may send a kill indication message to the fault handling module, i.e. proceed to step S307.

Step S307: the deadlock detector sends a kill indication message to the fault handling module.

As one way, after determining that the system service process has a deadlock event, the deadlock detector may send kill indication information to the failure processing module to instruct the failure processing module to kill the opposite process of the system service process, i.e. step S308 is performed. For example, the killing indication information may include an identifier of a process to be killed, where the identifier of the process to be killed may be an identifier of a peer process.

Step S308: the failure processing module kills the opposite process.

In some embodiments, when the fault processing module receives the killing instruction information transmitted by the log generating module, the fault processing module may kill the opposite process based on the identification of the opposite process, that is, close the opposite process. The opposite process may be the last process in the chain of the binder calls.

As one example, the form of the bundle of binder calls obtained by the log generation module is: a, B and C. Wherein, A represents a system service process, and when the system service process is determined to have a deadlock event, the fault processing module can kill the opposite process C, namely, close the process C.

In other embodiments, after the failure processing module kills the peer process, it may send a resume detection request to the failure detection module, i.e. go to step S309.

Step S309: the fault processing module sends a recovery detection request to the fault detection module.

Step S310: the fault detection module determines whether the electronic device resumes normal operation.

In one manner, after receiving the recovery detection request, the fault detection module may determine whether the electronic device recovers to normal operation when the waiting time of the system service process reaches a third specified duration. The normal operation may be that the system service process is switched from the blocking state to the normal operation state, i.e. the system watchdog exception is eliminated. The second specified duration may be 60s.

In addition, if the electronic equipment resumes normal operation, the fault detection module can continue to detect the system watchdog abnormality of the electronic equipment. If the electronic device does not resume normal operation, a log acquisition request is sent to the log generation module, and step S311 is performed.

Step S311: the fault detection module sends a log acquisition request to the log generation module.

Step S312: the log generation module acquires a second call chain and adds the second call chain to a second original log to obtain a second target log.

In some implementations, the log generation module may obtain the second call chain upon receiving the log obtaining request and add the second call chain to the second original log.

The second call chain may also include a binder chain and a lock chain. In addition, the binder chain includes call relationships between the host process and other processes. The lock chain comprises the lock relation, namely the lock holding relation, the lock waiting relation and the like among all threads in the same process. It should be noted that the second call chain may be the same as the first call chain or may be different from the first call chain, which is specific to the actual situation.

In this embodiment of the present application, the formats of the logs included in the second original log and the first original log are the same, and the difference between the two is that the time of generating the logs is different. In other words, the first log and the second target log contain substantially the same log content, except that the time of generation is different.

Step S313: the log generation module sends system restart indication information to the fault processing module.

In some embodiments, after the log generation module obtains the target log, it may send system restart instruction information to the fault handling module to instruct the fault handling module to restart the system of the electronic device.

Step S314: the fault handling module restarts the system.

In this embodiment of the present application, when the failure processing module receives the system restart instruction information, it may restart the system of the electronic device. Specifically, the fault handling module may directly kill the system service process to achieve a restart of the system. For example, the form of the link call chain acquired by the log generation module is: a, B and C. The failure processing module can directly close the process A when restarting the system, so that the system of the electronic equipment enters a restarting state.

It will be appreciated that the electronic device, in order to achieve the above-described functions, includes corresponding hardware and/or software modules that perform the respective functions. The steps of an algorithm for each example described in connection with the embodiments disclosed herein may be embodied in hardware or a combination of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Those skilled in the art may implement the described functionality using different approaches for each particular application in conjunction with the embodiments, but such implementation is not to be considered as outside the scope of this application.

The present embodiment also provides a computer storage medium having stored therein computer instructions which, when executed on an electronic device, cause the electronic device to perform the above-described related method steps to implement the log generation method in the above-described embodiments.

The present embodiment also provides a computer program product which, when run on a computer, causes the computer to perform the above-described related steps to implement the log generation method in the above-described embodiments.

In addition, embodiments of the present application also provide an apparatus, which may be specifically a chip, a component, or a module, and may include a processor and a memory connected to each other; the memory is used for storing computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory, so that the chip executes the log generating method in each method embodiment.

The electronic device, the computer storage medium, the computer program product, or the chip provided in this embodiment are used to execute the corresponding methods provided above, so that the beneficial effects thereof can be referred to the beneficial effects in the corresponding methods provided above, and will not be described herein.

It will be appreciated by those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and the parts shown as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

Any of the various embodiments of the application, as well as any of the same embodiments, may be freely combined. Any combination of the above is within the scope of the present application.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions to cause a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, or other various media capable of storing program codes.

The embodiments of the present application have been described above with reference to the accompanying drawings, but the present application is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those of ordinary skill in the art without departing from the spirit of the present application and the scope of the claims, which are also within the protection of the present application.

Claims

1. A log generation method, applied to an electronic device, the method comprising:

under the condition that the electronic equipment fails, acquiring a first original log related to the failure and acquiring a process identifier related to the failure;

acquiring a first call chain based on the process identifier, wherein the first call chain comprises a binder chain and a lock chain;

and adding the first call chain to the first original log to obtain a first target log.

2. The method of claim 1, wherein the obtaining the fault-related process identification comprises:

and if the fault is application non-response, acquiring a main process identifier corresponding to the abnormal application program, and taking the main process identifier as a process identifier related to the fault.

3. The method of claim 2, wherein after the obtaining the first target log, comprising:

and killing the process corresponding to the main process identifier.

4. The method of claim 1, wherein the obtaining the fault-related process identification comprises:

if the fault is abnormal in the system watchdog, the identification of the system service process is obtained, and the identification of the system service process is used as the process identification related to the fault.

5. The method of claim 4, wherein after the obtaining the first target log, comprising:

determining whether a deadlock event occurs to the system service process based on the lock chain;

if the system service process generates a deadlock event, determining an opposite end process of the system service process based on the binder chain, and killing the opposite end process.

6. The method of claim 5, wherein said killing said peer process is followed by:

if the electronic equipment does not recover to normal operation, a second call chain is obtained, and a second original log related to the fault is obtained;

and adding the second call chain to the second original log to obtain a second target log.

7. The method of claim 6, wherein after obtaining the second target log, comprising:

killing the system service process.

8. The method of any of claims 1 to 7, wherein the call depth of a process in the binder chain is 3 layers.

9. An electronic device, comprising:

one or more processors;

a memory;

and one or more computer programs, wherein the one or more computer programs are stored on the memory, which when executed by the one or more processors, cause the electronic device to perform the steps of: under the condition that the electronic equipment fails, acquiring a first original log related to the failure and acquiring a process identifier related to the failure;

10. The device of claim 9, wherein the computer program, when executed by the one or more processors, causes the electronic device to perform the steps of:

11. The device of claim 10, wherein the computer program, when executed by the one or more processors, causes the electronic device to perform the steps of:

and killing the process corresponding to the main process identifier.

12. The device of claim 9, wherein the computer program, when executed by the one or more processors, causes the electronic device to perform the steps of:

13. The device of claim 12, wherein the computer program, when executed by the one or more processors, causes the electronic device to perform the steps of:

14. The device of claim 13, wherein the computer program, when executed by the one or more processors, causes the electronic device to perform the steps of:

15. The device of claim 14, wherein the computer program, when executed by the one or more processors, causes the electronic device to perform the steps of:

killing the system service process.

16. The apparatus of any of claims 9 to 15, wherein a call depth of a process in the binder chain is 3 layers.

17. A computer readable storage medium comprising a computer program, characterized in that the computer program, when run on an electronic device, causes the electronic device to perform the log generation method of any of claims 1-8.