Method for collecting crash information and related device

Abstract

The application provides a kind of collection method of collapse information and related equipment, belong to software technical field, the method includes: when detecting abnormal information, the default processing function corresponding to the application program generating the abnormal information is replaced by target processing function, the abnormal information is used to indicate that the application program crashes, and the default processing function is used to detect the abnormal information;According to the target processing function, the sub-process of the application program is generated, and the collapse information of the application program is collected based on the sub-process.The application in application program crashes, the collapse information of application program is automatically collected by calling target processing function, and the collapse information of application program is collected in time, so as to improve the repair timeliness of application program.

Description

Technical Field

[0001] This invention relates to the field of software technology, and in particular to a method and related equipment for collecting crash information. Background Technology

[0002] When running an application on a terminal device, the application may crash.

[0003] When an application crashes, the default mechanism of the terminal is to store the application's crash information in a file. However, the collection of crash information depends on manual collection, which means that the crash information is not collected in time, resulting in the crashed application not being repaired in a timely manner. Summary of the Invention

[0004] This invention provides a method and related equipment for collecting crash information, in order to improve the timeliness of repairing crashed applications.

[0005] On one hand, the present invention provides a method for collecting crash information, including:

[0006] When an anomaly is detected, the default handling function corresponding to the application that generated the anomaly is replaced with the target handling function. The anomaly is used to indicate that the application has crashed, and the default handling function is used to detect the anomaly.

[0007] The application's subprocesses are generated according to the target processing function, and crash information of the application is collected based on the subprocesses.

[0008] In one embodiment, collecting the application's crash information based on the subprocess includes:

[0009] Based on the subprocess, parameters of various preset types are collected from the registers and memory corresponding to the application to obtain the crash information. The parameters of each preset type are used to indicate the reason for the application crash.

[0010] In one embodiment, obtaining the crash information by collecting parameters of various preset types from the registers and memory corresponding to the application based on the subprocess includes:

[0011] Based on the subprocess, parameters of various preset types are collected from the registers and memory corresponding to the application.

[0012] Generate symbolic parameters corresponding to the parameters of the preset type, the symbolic parameters being used to convert the parameters of the preset type into readable parameters;

[0013] The crash information is obtained based on the parameters of each preset type and the corresponding symbol parameters.

[0014] In one embodiment, after collecting the application's crash information based on the subprocess, the method further includes:

[0015] Replace the target processing function with the default processing function;

[0016] Control the application to exit operation.

[0017] In one embodiment, after collecting the application's crash information based on the subprocess, the method further includes:

[0018] Obtain the attribute parameters of the crash information, and send an upload request to the server based on the attribute parameters. The upload request is used to request the server to send an encryption key.

[0019] Receive the encryption key sent by the server, and encrypt the crash information according to the encryption key to obtain encrypted information;

[0020] The encrypted information is sent to the server.

[0021] In one embodiment, receiving the encryption key sent by the server includes:

[0022] Receive the upload interface information and encryption key sent by the server;

[0023] Sending the encrypted information to the server includes:

[0024] The crash information is sent to the upload interface corresponding to the interface information, so that the crash information is sent to the server through the upload interface.

[0025] In one embodiment, the crash information includes at least one of the following: processor architecture parameters corresponding to the application, operating system version parameters of the application, file name of the application, version number of the application, file name of the application's dynamic library, version number of the dynamic library, state of the application's registers, and data in the application's call stack.

[0026] On the other hand, the present invention also provides a device for collecting crash information, comprising:

[0027] The calling module is used to replace the default handling function corresponding to the application that generated the abnormal information with the target handling function when an abnormal information is detected. The abnormal information is used to indicate that the application has crashed, and the default handling function is used to detect the abnormal information.

[0028] The generation module is used to generate a subprocess of the application according to the target processing function, and to collect crash information of the application based on the subprocess.

[0029] On the other hand, the present invention also provides a device for collecting crash information, including: a memory and a processor;

[0030] The memory stores computer-executed instructions;

[0031] The processor executes the computer execution instructions stored in the memory, causing the processor to perform the crash information collection method described above.

[0032] On the other hand, the present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the crash information collection method described above.

[0033] On the other hand, the present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the crash information collection method described above.

[0034] The crash information collection method and related equipment provided by this invention, upon detecting abnormal information and determining that an application has crashed, replace the application's default handling function with a target handling function, thereby generating a child process of the application based on the target handling function, and then collecting the application's crash information based on the child process. In this invention, when an application crashes, the crash information is automatically collected by calling the target handling function, thus improving the timeliness of application repair. Attached Figure Description

[0035] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0036] Figure 1 This is a flowchart illustrating the first embodiment of the crash information collection method of the present invention;

[0037] Figure 2 This is a flowchart illustrating the second embodiment of the crash information collection method of the present invention;

[0038] Figure 3 This is a flowchart illustrating the third embodiment of the crash information collection method of the present invention;

[0039] Figure 4 This is an interactive diagram related to the crash information collection method of the present invention;

[0040] Figure 5 This is a schematic diagram of the modules of the crash information collection device of the present invention;

[0041] Figure 6 This is a schematic diagram of the hardware structure of the crash information acquisition device of the present invention.

[0042] The accompanying drawings have illustrated specific embodiments of this disclosure, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this disclosure to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0043] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0044] The technical solutions of the present invention and how they solve the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0045] Reference Figure 1 , Figure 1 This is a first embodiment of the crash information collection method of the present invention. The crash information collection method includes the following steps:

[0046] Step S101: When an abnormal message is detected, the default handling function corresponding to the application that generated the abnormal message is replaced with the target handling function. The abnormal message is used to indicate that the application has crashed, and the default handling function is used to detect the abnormal message.

[0047] In this embodiment, the execution entity is the crash information collection device. For ease of description, the term "device" will be used to refer to the crash information collection device below. The device can be any terminal device with an application installed, such as a mobile phone, tablet, or computer.

[0048] When an application is running, the default processing function for that application collects information from the application and analyzes it to determine if it is an exception. If the information includes memory out-of-bounds errors, division by zero operations, illegal instructions, etc., then it is considered an exception, meaning that the application has crashed and generated the exception. It can be understood that exception information is used to indicate an application crash, and the default processing function is used to detect exceptions.

[0049] The application may enter a blocked state due to waiting for error messages and error code. However, a crashed application is in a blocked state, requiring manual retrieval of its crash information. To address this, the device replaces the default handler function with a target handler function, which is a registered handler function whose purpose is to extract the application's crash information.

[0050] Step S102: Generate a child process of the application based on the target processing function, and collect the application's crash information based on the child process.

[0051] The device generates a child process of the application through the target processing function, and the crash information of the crashed application can be read through the child process.

[0052] Furthermore, after collecting crash information, the device replaces the target handling function with the default handling function, i.e., reinstalls the default handling function, and then exits the application, i.e., controls the application to exit execution. By reinstalling the default handling function, the device can continue to detect whether the running application has crashed using the default handling function. It should be noted that when exiting the application, the child processes are also terminated to save the device's computing resources.

[0053] The device can be a Linux operating system. The Linux kernel converts application crash information into a Coredump file. Coredump files need to be manually opened by the user to be generated, and the information recorded in the Coredump file includes information about the platform from which the crash information was collected. In this embodiment, the device uses the target processing function to call the clone system in the device to create a child process, and then the child process calls the ptrace system in the device to read the application crash information.

[0054] Furthermore, the above steps can be implemented using a tool installed in the device, such as Breakpad. Breakpad uses an embedded library file to collect application exception information, replaces the default handler function with a target handler function using the embedded library file, and then generates a child process using the target handler function. The crash information collected by the embedded library file can then be written into a dump file for storage. In this way, application crash information can be automatically obtained, and only application crash information is collected; the collected crash information does not include platform information, meaning the crash information is incompatible with the platform.

[0055] In this embodiment, upon detecting abnormal information and determining that the application has crashed, the application's default handling function is replaced with a target handling function. A child process for the application is then generated based on the target handling function, and crash information is collected from this child process. In this embodiment, when the application crashes, crash information is automatically collected by calling the target handling function, ensuring timely collection of crash information and improving the timeliness of application repair.

[0056] Reference Figure 2 , Figure 2 This is a second embodiment of the crash information collection method of the present invention. Based on the first embodiment, step S101 includes:

[0057] Step S201: Generate a child process of the application based on the target processing function.

[0058] Step S202: Based on the subprocess, collect parameters of various preset types from the registers and memory corresponding to the application to obtain crash information. The parameters of each preset type are used to indicate the reason for the application crash.

[0059] In this embodiment, after generating a child process based on the target processing function, the child process calls the ptrace system to collect parameters of various preset types from the application's registers and memory, thereby obtaining crash information. These preset type parameters are key information for the application crash; that is, the crash information includes these preset type parameters, and the cause of the application crash can be determined through these parameters.

[0060] The crash information includes at least one of the following: the processor architecture parameters corresponding to the application, the operating system version parameters of the application, the application's file name, the application's version number, the file name and version number of the application's dynamic libraries, the state of the application's registers, and the data in the application's call stack.

[0061] The device can write crash information into a minidump file. Compared to the existing Coredump file, since the crash information only includes key information about the application crash, the minidump file has a smaller data size, is easier to transmit, and thus has higher transmission efficiency, further improving the timeliness of application repair. In this embodiment, crash information can be written into a minidump file by embedding a file library, and the capture of exception information and acquisition of crash information can be achieved on hardware platforms such as x64, arm64, and mips64, so as to centrally analyze the crash information.

[0062] Furthermore, the device collects parameters of various preset types from the registers and memory corresponding to the application based on the subprocess, and then generates corresponding symbolic parameters of the preset types, thereby obtaining crash information based on the parameters of various preset types and the corresponding symbolic parameters.

[0063] Specifically, the preset type parameters include parameters for executable files and shared library versions. Since these parameters are not readable by the user, the device searches for suitable symbol files for them—that is, it finds suitable symbolic parameters—and generates a readable stack trace identifier for the preset type parameters based on these symbolic parameters. The stack trace identifier can be, for example, C / C++. Symbolic parameters can be implemented using components of a tool, such as a symbol generator, and this tool could be Breakpad.

[0064] In this embodiment, the application crash information can be obtained by acquiring parameters of various preset types. That is, only the relevant parameters of the application crash are collected, which reduces the amount of crash information data, improves the data transmission efficiency of crash information, and thus improves the timeliness of application repair.

[0065] Reference Figure 3 , Figure 3 This is a third embodiment of the crash information collection method of the present invention, based on the first or second embodiment. After step S102, it further includes:

[0066] Step S301: Obtain the attribute parameters of the crash information and send an upload request to the server based on the attribute parameters. The upload request is used to request the server to send the encryption key.

[0067] In this embodiment, the device needs to send crash information to the cloud for backup and storage. To do this, the device obtains attribute parameters of the crash information, such as the data size of the crash information, the filename of the crash information (crash information can be stored as a file), and the identifier of the application that crashed. The device sends an upload request to the server based on these attribute parameters; that is, the device generates an upload request based on the attribute parameters. The upload request is used to request the server to send an encryption key.

[0068] If the crash information is stored as a dump file, it needs to be transmitted via an interface, which can be a token-based interface. The device sends the upload request to the server via the token-based interface.

[0069] Step S302: Receive the encryption key sent by the server, and encrypt the crash information according to the encryption key to obtain encrypted information.

[0070] After receiving an upload request, the server parses the request to obtain attribute parameters, configures the encryption key using these parameters, and returns the encryption key to the device. If the upload request is sent to the server via the token interface, the server returns the encryption key to the token interface, and the device then retrieves the encryption key from the token interface.

[0071] Step S303: Send the encrypted information to the server.

[0072] After receiving the encryption key, the device encrypts the crash information using the key to obtain encrypted information, which is then sent to the server. The token interface can monitor whether the crash information has been uploaded repeatedly. That is, after the device encrypts the crash information, the token interface checks whether the encrypted information has already been uploaded. If it has not been uploaded, the token interface sends the encrypted information to the server.

[0073] Furthermore, uploading crash information also involves the server's upload interface. Transmitting crash information through the upload interface further ensures the security of the crash information. To this end, the device receives the upload interface information and encryption key from the server, and sends the encrypted information to the server, including sending the crash information to the upload interface corresponding to the interface information to transmit the crash information to the server through the upload interface. The upload interface can be an upload interface, and the interface information can be a URL (Uniform Resource Locator).

[0074] In this embodiment, the crash information is encrypted with an encryption key and then sent to the server. The crash information is backed up while ensuring data security.

[0075] Based on the above embodiments, the method for collecting crash information provided by the present invention will be briefly described.

[0076] Reference Figure 4 , Figure 4 The following is a flowchart illustrating the interaction process involved in the crash information collection method of this invention. The specific interaction steps are as follows:

[0077] 1. The device detects whether the application generates abnormal information. If detection information is detected, proceed to step 2.

[0078] 2. The device replaces the default processing function with the target processing function;

[0079] 3. The device calls the target processing function to generate a child process;

[0080] 4. The device collects application crash information through subprocesses;

[0081] 5. Attribute parameters for the device to send crash information to the server;

[0082] 6. The server returns the encryption key based on the attribute parameters;

[0083] 7. The device encrypts the crash information based on the encryption key;

[0084] 8. The device sends the encrypted crash information to the server.

[0085] The present invention also provides a device for collecting crash information, referring to Figure 5 The crash information collection device 500 includes:

[0086] Module 510 is called to replace the default handling function of the application that generated the exception information with the target handling function when an exception information is detected. The exception information is used to indicate that the application has crashed, and the default handling function is used to detect the exception information.

[0087] The production module 520 is used to generate child processes of the application based on the target processing function and to collect application crash information based on the child processes.

[0088] In one embodiment, the crash information acquisition device 500 includes:

[0089] The acquisition module is used to collect parameters of various preset types from the registers and memory corresponding to the application based on the subprocess, and obtain crash information. The parameters of each preset type are used to indicate the reason for the application crash.

[0090] In one embodiment, the crash information acquisition device 500 includes:

[0091] The acquisition module is used to acquire parameters of various preset types from the registers and memory of the application based on the subprocess;

[0092] The production module 520 is also used to generate symbolic parameters corresponding to preset type parameters. The symbolic parameters are used to convert preset type parameters into readable parameters.

[0093] The acquisition module is used to obtain crash information based on parameters of various preset types and their corresponding symbolic parameters.

[0094] In one embodiment, the crash information acquisition device 500 includes:

[0095] Module 510 is also used to replace the target processing function with the default processing function;

[0096] The control module is used to control the application's exit from operation.

[0097] In one embodiment, the crash information acquisition device 500 includes:

[0098] The acquisition module is used to obtain the attribute parameters of the crash information and send an upload request to the server based on the attribute parameters. The upload request is used to request the server to send the encryption key.

[0099] The receiving module is used to receive the encryption key sent by the server and encrypt the crash information according to the encryption key to obtain encrypted information;

[0100] The sending module is used to send encrypted information to the server.

[0101] In one embodiment, the crash information acquisition device 500 includes:

[0102] The receiving module is used to receive the interface information and encryption key of the upload interface sent by the server.

[0103] The sending module is used to send crash information to the upload interface corresponding to the interface information, so that the crash information can be sent to the server through the upload interface.

[0104] In one embodiment, the crash information includes at least one of the following: processor architecture parameters corresponding to the application, operating system version parameters of the application, application file name, application version number, application dynamic library file name, dynamic library version number, application register status, and data in the application's call stack.

[0105] Figure 6 This is a hardware structure diagram of a crash information acquisition device according to an exemplary embodiment.

[0106] The crash information acquisition device 600 may include: a processor 601, such as a CPU, a memory 602, and a transceiver 603. Those skilled in the art will understand that... Figure 6 The structure shown does not constitute a limitation on the device for acquiring crash information and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Memory 602 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0107] The processor 601 can call computer programs or computer execution instructions stored in the memory 602 to complete all or part of the steps of the above-described method for collecting crash information.

[0108] Transceiver 603 is used to receive information sent by external devices and to send information to external devices.

[0109] A non-transitory computer-readable storage medium, wherein when the instructions (computer-executable instructions) in the storage medium are executed by the processor of a crash information acquisition device, the crash information acquisition device is able to execute the aforementioned crash information acquisition method.

[0110] A computer program product includes a computer program that, when executed by a processor of a crash information acquisition device, enables the crash information acquisition device to perform the aforementioned crash information acquisition method.

[0111] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0112] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for collecting crash information, characterized in that, include: When an anomaly is detected, the default handling function corresponding to the application that generated the anomaly is replaced with a target handling function. The anomaly indicates that the application has crashed, and the default handling function is used to detect the anomaly. The target handling function is a registered handling function used to extract the crash information of the application. The application's subprocesses are generated according to the target processing function, and the application's crash information is collected based on the subprocesses. The collection of application crash information based on the subprocess includes: Based on the subprocess, parameters of various preset types are collected from the registers and memory corresponding to the application; the parameters of each preset type are used to indicate the cause of the application crash; symbolic parameters corresponding to the parameters of the preset types are generated, and the symbolic parameters are used to convert the parameters of the preset types into readable parameters; the crash information is obtained according to the parameters of each preset type and the corresponding symbolic parameters, and the crash information is written into a minidump file; After collecting the application's crash information based on the subprocess, the method further includes: Obtain the attribute parameters of the crash information, and send an upload request to the server based on the attribute parameters. The upload request is used to request the server to send an encryption key. The system receives an encryption key sent by the server and encrypts the crash information using the encryption key to obtain encrypted information; then sends the encrypted information to the server.

2. The method for collecting crash information according to claim 1, characterized in that, After collecting the application's crash information based on the subprocess, the method further includes: Replace the target processing function with the default processing function; Control the application to exit operation.

3. The method for collecting crash information according to claim 1, characterized in that, The encryption key received from the server includes: Receive the upload interface information and encryption key sent by the server; Sending the encrypted information to the server includes: The crash information is sent to the upload interface corresponding to the interface information, so that the crash information is sent to the server through the upload interface.

4. The method for collecting crash information according to any one of claims 1-3, characterized in that, The crash information includes at least one of the following: the processor architecture parameters corresponding to the application, the operating system version parameters of the application, the file name of the application, the version number of the application, the file name of the application's dynamic library, the version number of the dynamic library, the state of the application's registers, and the data in the application's call stack.

5. A device for collecting crash information, characterized in that, include: The calling module is used to replace the default handling function corresponding to the application that generated the abnormal information with a target handling function when an abnormal information is detected. The abnormal information is used to indicate that the application has crashed, and the default handling function is used to detect the abnormal information. The target handling function is a registered handling function used to extract the crash information of the application. A generation module is used to generate a subprocess of the application according to the target processing function, and to collect crash information of the application based on the subprocess; The acquisition module is used to acquire parameters of various preset types from the registers and memory corresponding to the application based on the subprocess; the parameters of each preset type are used to indicate the reason for the application crash; The production module is also used to generate symbolic parameters corresponding to the parameters of the preset type, and the symbolic parameters are used to convert the parameters of the preset type into readable parameters; The acquisition module is used to acquire the crash information according to the parameters of each preset type and the corresponding symbol parameters, and write the crash information into a minidump file; The acquisition module is further configured to acquire the attribute parameters of the crash information and send an upload request to the server based on the attribute parameters. The upload request is used to request the server to send an encryption key. A receiving module is used to receive the encryption key sent by the server and encrypt the crash information according to the encryption key to obtain encrypted information; The sending module is used to send the encrypted information to the server.

6. A device for collecting crash information, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the crash information acquisition method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the crash information collection method as described in any one of claims 1 to 4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method for collecting crash information as described in any one of claims 1-4.

Images