CN114741224A

CN114741224A - Monitoring method, device and apparatus for crash log and storage medium

Info

Publication number: CN114741224A
Application number: CN202210397131.2A
Authority: CN
Inventors: 梅文滔; 胡循锋
Original assignee: Maojia Technology Guangdong Co ltd
Current assignee: Maojia Technology Guangdong Co ltd
Priority date: 2022-04-15
Filing date: 2022-04-15
Publication date: 2022-07-12

Abstract

The invention discloses a monitoring method, a device and a storage medium of a crash log, wherein the method comprises the following steps: if the running application program is monitored to be abnormal, acquiring abnormal data corresponding to the application program; and screening the abnormal data based on the abnormal type corresponding to the abnormal type, and storing the screened abnormal data. By adopting the method and the device, the problem of crash can be solved more timely and accurately by developers by rapidly checking the abnormity of the application program.

Description

Monitoring method, device and apparatus for crash log and storage medium

Technical Field

The invention relates to the technical field of computer application, in particular to a method, equipment and device for monitoring a crash log and a storage medium.

Background

For many software applications at present, users often have abnormal problems when using software, and then have no policy, and the problems are solved through layer-upon-layer feedback and software, so that the problems are time-consuming and have a solution period, and the problems from recurrence to troubleshooting are time-consuming, labor-consuming and irreparable.

Android (Android) is a Linux-based operating system with free and open source codes, and is mainly used for mobile devices such as smart phones and tablet computers. Due to the good open source characteristic of the android system, more and more people are engaged in android application program development, and further, the appearance of multi-version android systems and application programs in the market is promoted. The compatibility of the system is poor due to a plurality of versions, so that fragmentation of the android system is serious, the phenomenon of application program crash often occurs, and the user experience is poor due to the fact that some serious crash problems occur after the software product is released. The crash is an inevitable matter in development, considering that a crash may be caused by insufficient comprehensive codes, a poor network environment and a headache fragmentation problem, and what is worse, after an application program crashes, a developer cannot know why the program crashes, so that it is necessary to know crash information when a user crashes. Therefore, the collection of crash information becomes very important. However, in the prior art, there is no good method for collecting crash information.

Disclosure of Invention

The invention provides a monitoring method, equipment, a device and a storage medium of crash logs, and aims to solve the technical problem that effective abnormal data cannot be well collected after a program is abnormal.

In order to achieve the above object, the present invention provides a method for monitoring a crash log, including:

if the running application program is monitored to be abnormal, acquiring abnormal data corresponding to the application program;

and screening the abnormal data based on the abnormal type corresponding to the abnormal data, and storing the screened abnormal data.

In order to achieve the above object, the present application further provides a monitoring apparatus for crash logs, including:

the data acquisition module is used for acquiring abnormal data corresponding to the application program if the running application program is monitored to be abnormal;

and the data screening module is used for screening the abnormal data based on the abnormal type corresponding to the abnormal data and storing the screened abnormal data.

In order to achieve the above object, the present application further provides a monitoring device for crash logs, where the monitoring device for crash logs includes a memory, a processor, and a monitoring program for crash logs, which is stored in the memory and can be run on the processor, and the processor implements the steps of the monitoring method for crash logs when executing the monitoring program for crash logs.

In order to achieve the above object, the present application further provides a computer-readable storage medium, where a monitoring program of the crash log is stored on the computer-readable storage medium, and the monitoring program of the crash log is executed by a processor to implement the steps of the monitoring method of the crash log.

In the application, the application program is monitored, if the application program is monitored to have abnormal behaviors and cause breakdown, abnormal data corresponding to the abnormal behaviors are obtained, then the abnormal data are screened, and the screened abnormal data are stored, so that development and maintenance personnel can observe the abnormity of the application program based on the stored abnormal data, the breakdown problem is solved more timely and accurately, and the phenomenon that a large amount of time is consumed to investigate the cause of the breakdown is avoided.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the structures shown in the drawings without creative efforts.

FIG. 1 is a block diagram illustrating a monitoring method for crash logs according to an embodiment of the present invention;

FIG. 2 is a flowchart of a monitoring method for crash logs according to an embodiment of the present invention;

fig. 3 is a schematic block diagram of a crash log snooping method according to an embodiment of the present invention.

Detailed Description

It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the invention.

Referring to fig. 1, fig. 1 is a schematic diagram illustrating a hardware structure of a monitoring device for crash logs according to various embodiments of the present invention. The monitoring device of the crash log comprises an execution module 01, a memory 02, a processor 03, a battery system and the like. Those skilled in the art will appreciate that the apparatus shown in fig. 1 may also include more or fewer components than those shown, or combine certain components, or a different arrangement of components. The processor 03 is connected with the memory 02 and the execution module 01 respectively, the memory 02 stores a monitoring program of the crash log, and the monitoring program of the crash log is executed by the processor 03 at the same time.

The execution module 01 may obtain abnormal data corresponding to an application program if it is monitored that the running application program is abnormal; and screening the abnormal data based on the abnormal type corresponding to the abnormal data, and storing the screened abnormal data. And simultaneously feeds back the above information to the processor 03.

The memory 02 may be used to store software programs and various data. The memory 02 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, application programs required for a plurality of functions, and the like; the storage data area may store data or information created according to the use of the internet of things terminal, or the like. Further, the memory 02 may include high speed random access memory, and may also include non-volatile memory, such as a plurality of magnetic disk storage devices, flash memory devices, or other volatile solid state storage devices.

The processor 03, which is a control center of the processing platform, is connected to each part of the whole internet of things terminal by using various interfaces and lines, and executes various functions and processing data of the internet of things terminal by running or executing software programs and/or modules stored in the memory 02 and calling data stored in the memory 02, thereby performing overall monitoring on the monitoring device of the crash log. Processor 03 may include one or more processing units; preferably, the processor 03 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 03.

Those skilled in the art will appreciate that the listening device structure of the crash log shown in FIG. 1 does not constitute a limitation of the device and may include more or fewer components than shown, or some components in combination, or a different arrangement of components.

Various embodiments of the method of the present invention are presented in terms of the above-described hardware architecture.

In order to solve the above problem, the present application provides a method for monitoring a crash log, and referring to fig. 2, in a first embodiment of the method for monitoring a crash log of the present invention, the method for monitoring a crash log includes:

step S100, if the running application program is monitored to be abnormal, abnormal data corresponding to the application program is obtained;

in this embodiment, the modes of monitoring the application program include at least two, the first monitoring mode is global exception monitoring, that is, a global monitoring entry is defined, a global exception handling class-based interface for implementing exception handling procedures is set, and the global exception handling is set as exception handling monitoring; the second monitoring mode is single-thread exception monitoring, that is, a single-thread interface for implementing exception handling procedures is set, and exception handling monitoring is set for different threads independently. In an embodiment, the global exception monitoring may be self-defining a global Application, and simultaneously self-defining a CrashHandler, and then setting the CrashHandler as a global exception handling class for performing global exception monitoring; in another embodiment, the single-thread exception snooping is only for a single thread, and when an uncaptured exception occurs in an application program, the JAVA virtual machine queries the uncaughtexeceptionhandler of the thread through a method of getdefaultunc enucaoutexceptionhandler for snooping the exception in the thread.

In this embodiment, no matter the monitoring is performed through global exception monitoring or single-thread exception monitoring, the exception data of the application program may be obtained only by monitoring that the application program is abnormal. For example, when an application program starts to run, the monitoring interfaces are loaded to the application programs respectively, and the monitoring interfaces are initialized respectively; the monitoring interfaces are used for monitoring whether the Native layer has an exception or not. .

Specifically, a listening interface is loaded to each application program. In this embodiment, the monitor interface is implemented by a listener, where the listener is a common Java program that implements a specific interface, and the listener is configured to monitor a method call or an attribute change condition of another Java object. Each snoop interface internally contains several abstract methods for handling the events. Each application typically has a listening interface corresponding to a listener, and each interface may also define one or more listening methods. These snoop methods are invoked when a particular event occurs. For example, when a method call or an attribute change event occurs to a snooped object, a particular snoop method set in a snoop interface is executed immediately. The monitoring interface in the application is used for monitoring whether the Native layer is abnormal or not. Linux has a signal mechanism, which is an important way for Linux inter-process communication, and Linux signals are used for normal task scheduling and inter-process communication on one hand. And on the other hand, the system is also responsible for monitoring the abnormity and the interruption of the system, and when the system is abnormal, the Linux kernel generates abnormal data and informs the current process. The monitor receives the abnormal data notification sent by the Linux kernel, namely knows that the Native layer is abnormal, and then acquires the abnormal data when the abnormality occurs.

And step S200, screening the abnormal data based on the abnormal type corresponding to the abnormal data, and storing the screened abnormal data.

In this embodiment, after the abnormal data when the application program is abnormal is obtained, the abnormal data needs to be further screened, and the screening rule is set in advance by a person skilled in the art and can be adjusted in real time. Specifically, there are many reasons for causing an application program exception on a Native level, for example, an exception occurs in hardware, an illegal memory access, a memory crash, or a library called by a process finds an error, and sending a suspend signal to itself so that the process is terminated, etc. all cause the application program to be abnormal. The abnormal data refers to useful software and hardware information involved and involved in the running process of the application program, for example, the abnormal data may be a logcat log recording the abnormal occurrence process, may be information of the terminal device being used, and may be basic information of the application program which crashes, and the like. Collecting such abnormal data can help program developers to comprehensively understand the specific reasons of Native crash. Therefore, when an application program is abnormal, different abnormal data needs to be collected and screened, and then the screened abnormal data needs to be stored.

According to the application program monitoring method and device, the application program is monitored, if the application program is monitored to have abnormal behaviors and cause collapse, abnormal data corresponding to the abnormal behaviors are obtained, then the abnormal data are screened, and the screened abnormal data are stored, so that development and maintenance personnel can observe the abnormity of the application program based on the stored abnormal data, the collapse problem is solved more timely and accurately, and a large amount of time is prevented from being consumed to investigate the collapse reason.

Specifically, before capturing the abnormal data, an abnormal interface needs to be captured, and the abnormal data is acquired through the abnormal interface. In this embodiment, if abnormal data occurs in the application program, the abnormal data may be obtained by capturing the abnormal interface. The abnormal interface is an acquisition interface of abnormal data. Specifically, if an uncaught exception occurs in the Native layer (exception is not captured), exception data can be obtained through the capture exception interface.

In addition, there are many reasons for causing an exception to an application. Namely, there are many exception types corresponding to the exception data, and the exception types corresponding to the exception data can be obtained according to the exception data, and the exception data is screened based on the exception types. Namely, one part of abnormal data of the abnormal type is stored, and the other part of abnormal data of the abnormal type is filtered.

As described above, for example, when a hardware exception, a code exception, an illegal memory access, a memory crash, or a library discovery error of a process call occurs, an abort signal is sent to the application itself so that a process is terminated, and other exception types all cause an exception to occur to the application. In one embodiment, three exception types of exception data, namely, exception data when a hardware exception occurs, code exception data and illegal memory access data, need to be stored, and other exception types need to be filtered.

For example, the following C code:

int*p＝0；

*p＝1；

when the second line of code is executed, the program crashes. The pointer p defined here is a null pointer, and assignment of the null pointer is impossible, which can cause Native exception and further crash. Such exception types may be attributed to code exceptions.

Therefore, the abnormal data of the time can be stored. According to the method and the device, the abnormal data with the higher priority can be quickly obtained by obtaining the abnormal type corresponding to the abnormal data and screening the abnormal data according to the abnormal type, so that the program can be conveniently maintained, and the memory can be saved.

In an embodiment, if it is monitored that an operating application program is abnormal, after obtaining abnormal data corresponding to the application program, the method further includes:

and sending abnormal prompt information based on the abnormal data, wherein the abnormal prompt information is used for prompting the user of the occurrence of the abnormality.

In an embodiment, if it is monitored that an operating application program is abnormal, obtaining abnormal data corresponding to the application program includes:

and if monitoring that the running application program is about to crash or has crashed, acquiring abnormal data corresponding to the running application program which is about to crash or has crashed.

Typically, if an application is abnormal, it will further cause a crash, and when the crash occurs, the system will kill the executing application, causing the application to flash back, or the system will prompt the user that the application has stopped running. However, in this embodiment, if the system monitors that the application program is abnormal and the abnormality causes the application program to crash soon or monitors that the application program crashes, the system acquires abnormal data corresponding to the crash, and sends an abnormality prompt message to the user based on the abnormal data to prompt the user that the application program is abnormal and may cause the crash soon or the crash.

If the application program is not crashed, the abnormal prompt information can prompt the user to make a response so as to avoid the occurrence of crash; if the application program is crashed, the abnormal prompt information can prompt the user to prevent the application program running in the kill of the system, and the influence of crash is prevented from being further expanded.

In an embodiment, the screening processing of the abnormal data based on the abnormal type corresponding to the abnormal data, and storing the screened abnormal data includes:

determining an abnormal type corresponding to the abnormal data according to a preset abnormal type priority;

if the abnormal type of the abnormal data is the important priority, setting the abnormal data as the important abnormal data, and storing the important abnormal data; the important abnormal data is abnormal data which is about to be uncontrollable, and the important priority is an abnormal type corresponding to the important abnormal data.

In an embodiment, after determining the exception type corresponding to the exception data according to the preset exception type priority, the method further includes:

if the abnormal type of the abnormal data is the common priority, setting the abnormal data as the common abnormal data, and filtering the common abnormal data; the general abnormal data is controllable abnormal data, and the general priority is an abnormal type corresponding to the general abnormal data.

In this embodiment, according to the exception type priority of the exception type of the exception data, the exception data may be divided into important exception data and general exception data, and the priority of the exception data is set in advance by a person skilled in the art or a user, and may be adjusted in real time according to a specific situation. Specifically, a person skilled in the art may perform priority setting on the abnormal data according to the influence caused by the abnormal data, and may also perform priority setting on the abnormal data according to the attention degree set by the user.

In some embodiments, priority setting is performed on the abnormal data according to the influence caused by the abnormal data, and in the abnormal types corresponding to the abnormal data, the crash caused by some abnormal types is controllable, and the crash caused by some abnormal types is uncontrollable; in order to avoid an excessive influence caused by the uncontrollable data exception, the uncontrollable exception data needs to be screened out for storage, so that the exception type of the uncontrollable exception data is set as an important priority, and the exception data with the important priority is screened out for storage, so that a person skilled in the art can maintain and repair the application program in a subsequent process based on the exception data with the important priority.

In other embodiments, the anomaly data is classified according to a user's attention. If the user wants to analyze the type of the abnormal condition of the illegal memory access, the type of the illegal memory access can be set as an important priority, and other types of the abnormal condition are set as a common priority. Then storing the abnormal data with important priority and filtering the abnormal data with general priority. Through the data classification storage mode in the embodiment, abnormal data concerned by a user can be collected in a centralized manner, so that the user can conveniently and rapidly obtain the abnormal data of the desired abnormal type for unified analysis.

In addition, in this embodiment, all types may be set as important priorities, or all types may be set as general priorities, and all abnormal data may be flexibly divided into three, four, or even more priorities according to the data type, which is not limited herein. Through the division of the abnormal types, a user can only store abnormal data which has higher importance to the user, and filter out some abnormal data with low importance, so that the memory is saved.

In one embodiment, storing the filtered exception data includes:

and storing the screened abnormal data into a specified path in the equipment or the storage disk.

In this embodiment, the abnormal data records main information when the crash occurs, and a program developer can find the cause of the crash by analyzing the abnormal data. In addition, duplicate information may occur in the abnormal data, and therefore, a deduplication process is required before the abnormal data is stored. Further, the step of storing the filtered abnormal data may be writing the filtered abnormal data into a specified path in a device where the application program runs, or storing the filtered abnormal data into a specified path in a storage disk, or uploading the filtered abnormal data to a cloud server. It is noted that the exception data may be stored in one of the above manners alone, or in a plurality of the above manners. After the abnormal data is stored, a developer can acquire the stored abnormal data according to a storage path or a storage mode of the abnormal data, and maintain and repair the application program through analysis of the abnormal data.

In one embodiment, after storing the filtered abnormal data in a specified path in the device or the storage disk, the method further includes:

if receiving abnormal data, deriving a request;

and carrying out identity verification on the export request, and exporting the screened abnormal data if the identity verification passes.

In this embodiment, after the filtered abnormal data is stored in the device, the storage disk, or the cloud server in the form of log information, if the user wants to read or derive the stored abnormal data, the identity check is required. The user can read or derive the stored abnormal data only if the identity verification is passed, and the user cannot read or derive the stored abnormal data if the identity verification is not passed.

As shown in fig. 3, the present invention further provides a monitoring apparatus for crash log, where the monitoring apparatus for crash log includes:

the data acquisition module A10 is used for acquiring abnormal data corresponding to the application program if the running application program is monitored to have abnormality;

and the data screening module a20 is configured to perform screening processing on the abnormal data based on the abnormal type corresponding to the abnormal data, and store the screened abnormal data.

As an implementation manner of the present application, the data obtaining module a10 includes:

an abnormality presentation unit: and sending an abnormal prompt message based on the abnormal data, wherein the abnormal prompt message is used for prompting the user of the occurrence of the abnormality.

As an implementation manner of the present application, the data obtaining module a10 further includes:

the data acquisition unit is used for acquiring abnormal data corresponding to the running application program which is about to run or has crashed if monitoring that the running application program is about to crash or has crashed.

As an implementation manner of the present application, the data obtaining module a20 includes:

the determining unit is used for determining the abnormal type corresponding to the abnormal data according to the preset abnormal type priority;

a first setting unit, configured to set the abnormal data as important abnormal data and store the important abnormal data if an abnormal type of the abnormal data is an important priority; the important abnormal data is abnormal data which is not to be controlled, and the important priority is an abnormal type which has a corresponding relation with the important abnormal data.

As an implementation manner of the present application, the data obtaining module a20 further includes:

the second setting unit is used for setting the abnormal data as general abnormal data and filtering the general abnormal data if the abnormal type of the abnormal data is general priority; the general abnormal data is controllable abnormal data, and the general priority is an abnormal type corresponding to the general abnormal data.

and the storage unit is used for storing the screened abnormal data into a specified path in equipment or a storage disk.

a receiving unit, configured to derive a request if an abnormal data is received;

and the verification unit is used for carrying out identity verification on the export request, and exporting the screened abnormal data if the identity verification passes.

The monitoring device of the crash log is used for realizing the monitoring method of the crash log when executing.

The invention also provides a monitoring device of the crash log, the monitoring device of the crash log comprises a memory, a processor and a monitoring program of the crash log, the monitoring program of the crash log is stored on the memory and can run on the processor, and the steps of the method of each embodiment of the invention are realized when the processor executes the monitoring program of the crash log.

The invention further provides a computer-readable storage medium, on which a monitoring program of the crash log is stored, and when being executed by a processor, the monitoring program of the crash log implements the steps of the monitoring method of the crash log. The storage medium includes a computer-readable storage medium, which may be the Memory in fig. 1, and may also be at least one of a ROM (Read-Only Memory)/RAM (Random Access Memory), a magnetic disk, and an optical disk, where the storage medium includes several instructions to enable an internet of things terminal device (which may be a mobile phone, a computer, a server, an internet of things terminal, or a network device) having a processor to execute the method in the embodiments of the present invention.

In the present invention, the terms "first", "second", "third", "fourth" and "fifth" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance, and those skilled in the art can understand the specific meanings of the above terms in the present invention according to specific situations.

In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in multiple embodiments or examples of the invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

Although the embodiment of the present invention has been shown and described, the scope of the present invention is not limited thereto, it should be understood that the above embodiment is illustrative, and not restrictive, and that those skilled in the art can make changes, modifications and substitutions to the above embodiment within the scope of the present invention, and that these changes, modifications and substitutions are included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for snooping a crash log, comprising:

2. The method according to claim 1, wherein after obtaining the abnormal data corresponding to the application program if it is monitored that the running application program has an abnormality, the method further comprises:

and sending abnormal prompt information based on the abnormal data, wherein the abnormal prompt information is used for prompting a user of abnormality.

3. The method as claimed in claim 1, wherein the obtaining of the abnormal data corresponding to the application program if it is monitored that the running application program has an abnormality comprises:

if the running application program is about to crash or is crashed, obtaining abnormal data corresponding to the running application program which is about to crash or is crashed.

4. The method as claimed in claim 3, wherein the screening the abnormal data based on the abnormal type corresponding to the abnormal data and storing the screened abnormal data comprises:

if the abnormal type of the abnormal data is the important priority, setting the abnormal data as important abnormal data, and storing the important abnormal data; the important abnormal data is abnormal data which is about to be uncontrollable, and the important priority is an abnormal type corresponding to the important abnormal data.

5. The method as claimed in claim 4, wherein after determining the exception type corresponding to the exception data according to the preset exception type priority, the method further comprises:

if the abnormal type of the abnormal data is a general priority, setting the abnormal data as general abnormal data, and filtering the general abnormal data; the general abnormal data is controllable abnormal data, and the general priority is an abnormal type corresponding to the general abnormal data.

6. The method of any one of claims 1-5, wherein storing the filtered anomaly data comprises:

and storing the screened abnormal data into a specified path in equipment or a storage disk.

7. The method of claim 6, wherein after storing the filtered exception data in a specified path in a device or storage disk, the method further comprises:

if receiving abnormal data, deriving a request;

8. An apparatus for snooping crash logs, comprising:

9. A crash log snooping device, wherein the crash log snooping device comprises a memory, a processor and a crash log snooping program stored on the memory and operable on the processor, and the processor executes the crash log snooping program to implement the crash log snooping method steps of any one of claims 1 to 7.

10. A computer-readable storage medium, having stored thereon a listener of a crash log, the listener of the crash log, when executed by a processor, implementing the steps of the method of listening to a crash log according to any one of claims 1 to 7.