Exception handling method, device, electronic device and computer storage medium

Abstract

Embodiments of the present invention provide an exception handling method, apparatus, electronic device, and computer storage medium. The exception handling method includes: obtaining exception backtrace information of an operating system where an exception occurred and information about the operating system; filtering interference information in the exception backtrace information, and performing feature extraction on the filtered exception backtrace information to obtain exception feature data; generating an exception identifier for identifying the exception based on the exception feature data, and reporting the exception identifier in correspondence with the operating system information.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer technology, and in particular to an exception handling method, device, electronic device, and computer storage medium. Background Art

[0002] Most of the existing exception handling solutions match the corresponding error code based on the information before the system crashes after the system crashes, and then display the corresponding error code to the user or report the error code.

[0003] However, the information before the system crash contains a lot of interference information, which may cause the above method to fail to match the correct error code, or the matched error code cannot correctly characterize the abnormality that occurred, causing great obstacles to subsequent abnormality statistics. Summary of the Invention

[0004] In view of this, an embodiment of the present invention provides an exception handling solution to at least partially solve the above problems.

[0005] According to a first aspect of an embodiment of the present invention, there is provided an exception handling method, comprising: obtaining exception backtrace information of an operating system where an exception occurs and information about the operating system; filtering interference information in the exception backtrace information, and performing feature extraction on the filtered exception backtrace information to obtain exception feature data; generating an exception identifier for identifying the exception based on the exception feature data, and reporting the exception identifier in correspondence with the information of the operating system.

[0006] According to a second aspect of an embodiment of the present invention, there is provided an exception handling method, comprising: obtaining exception information of an operating system exception reported by multiple terminals, wherein the exception information comprises: information of the operating system and an exception identifier of the exception, the exception identifier being generated based on exception feature data obtained after interference information filtering and feature extraction of the operating system's exception backtracing information; and performing operating system-based exception statistics on the multiple terminals based on the operating system information and the exception identifier.

[0007] According to a third aspect of an embodiment of the present invention, there is provided an exception handling device, comprising: an information acquisition module, configured to acquire exception backtrace information of an operating system where an exception occurs and information about the operating system; a feature acquisition module, configured to filter interference information in the exception backtrace information, and perform feature extraction on the filtered exception backtrace information to obtain exception feature data; and a reporting module, configured to generate an exception identifier for identifying the exception based on the exception feature data, and report the exception identifier in correspondence with the information of the operating system.

[0008] According to a fourth aspect of an embodiment of the present invention, there is provided an exception handling device, comprising: an exception information acquisition module, for acquiring exception information of an operating system exception reported by multiple terminals, wherein the exception information includes: information of the operating system and an exception identifier of the exception, the exception identifier being generated based on exception feature data obtained after interference information filtering and feature extraction of the exception backtracing information of the operating system; and a statistics module, for performing operating system-based exception statistics on the multiple terminals based on the operating system information and the exception identifier.

[0009] According to a fifth aspect of an embodiment of the present invention, an electronic device is provided, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform operations corresponding to the above-mentioned exception handling method.

[0010] According to a sixth aspect of an embodiment of the present invention, a computer storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the above-mentioned exception handling method is implemented.

[0011] According to the exception handling solution provided by an embodiment of the present invention, exception backtrace information of the operating system where the exception occurred and information about the operating system are obtained, and information about the process in which the exception occurred in the operating system can be obtained through the obtained backtrace information; interference information in the exception backtrace information is filtered, and information that interferes with the process of determining the exception in the exception backtrace information can be filtered out, and then feature extraction is performed on the filtered exception backtrace information to obtain exception feature data, and the exception feature data can represent core information of the exception process. Therefore, an exception identifier for identifying the exception is generated based on the exception feature data, and the exception identifier is reported in correspondence with the information of the operating system, ensuring that the reported information can accurately identify the occurred exception for statistical purposes. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0013] Figure 1A This is a flowchart of a method for handling an exception according to the first embodiment of the present invention;

[0014] Figure 1B A schematic diagram of a usage scenario;

[0015] Figure 2A A flowchart of an exception handling method according to an embodiment of the present invention;

[0016] Figure 2B A flowchart of the steps for executing the exception handling process;

[0017] Figure 3 A flowchart of the steps of an exception handling method implemented according to the present invention;

[0018] Figure 4A A flowchart of an exception handling method according to an embodiment of the present invention;

[0019] Figure 4B A schematic diagram of a usage scenario;

[0020] Figure 5 2 is a schematic structural diagram of an exception handling device according to an embodiment of the present invention;

[0021] Figure 6 2 is a schematic structural diagram of an exception handling device according to an embodiment of the present invention;

[0022] Figure 7 The figure is a structural diagram of an electronic device. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in the embodiments of the present invention should fall within the scope of protection of the embodiments of the present invention.

[0024] The specific implementation of the embodiment of the present invention is further described below with reference to the accompanying drawings of the embodiment of the present invention.

[0025] Example 1

[0026] Figure 1A FIG. 1 is a flowchart of a method for handling an exception according to the first embodiment of the present invention; FIG. Figure 1A As shown, it includes:

[0027] S102: Obtain exception backtrace information of the operating system where the exception occurs and information about the operating system.

[0028] First, in order to clearly illustrate the solution provided by this application, a brief description of the exceptions in the operating system is first given.

[0029] An operating system (OS) is a computer program that manages computer hardware and software resources. In the computer field, the OS is the most fundamental and important underlying system software in computing devices. It manages and configures memory, prioritizes system resource supply and demand, operates the network, and manages the file system.

[0030] When the operating system cannot work properly, an exception occurs. An exception (or crash) is an unexpected event that occurs during the operation of the operating system or the application software in the operating system, which forces the normal process to be interrupted and the exception handling process to be switched to.

[0031] The exceptions in this step mainly include hardware-level exceptions, which generally refer to hardware-defined exceptions such as the CPU, and are usually triggered by hardware. Examples of exceptions include system reset, undefined instruction, data abort, memory out-of-bounds access, prefetch abort, etc. Of course, the exceptions in this embodiment may also be other exceptions, which are not limited in this embodiment.

[0032] When an exception occurs in the operating system, the thread that caused the exception will be terminated. If the exception is caused by application software, the application software will terminate its operation. If the exception is caused by the operating system, the operating system will terminate its operation, that is, the system crashes. The existence or frequent occurrence of exceptions will result in a poor user experience.

[0033] In an embodiment of the present application, if it is determined that an exception occurs in the operating system, the exception backtrace information of the operating system where the exception occurs and the information of the operating system are obtained.

[0034] The exception backtrace information may be information obtained by backtracing the operating system when an exception occurs, and the exception backtrace information includes core information about the exception that occurred in the operating system, such as the cause of the exception, etc. It should be understood that the above is only an example and does not limit the present application.

[0035] The operating system information is used to identify the operating system, and may specifically include the type of operating system, the version number of the operating system, etc. It should be understood that the above is only an example and is not intended to limit the present application.

[0036] S104: Filter the interference information in the abnormal backtracking information, and extract features from the filtered abnormal backtracking information to obtain abnormal feature data.

[0037] In this embodiment, interference information is information in the exception backtrace information that interferes with the process of determining the exception. Interference information can be, for example, dynamic information or random information in the exception backtrace information. By filtering the interference information, the remaining exception backtrace information can be valid information corresponding to the exception.

[0038] By performing feature extraction on the abnormal backtracking information after filtering out the interference information, abnormal feature data corresponding to the core information of the abnormality can be obtained, thereby generating an abnormality identifier for characterizing the abnormality through subsequent steps.

[0039] S106: Generate an abnormality identifier for identifying the abnormality according to the abnormality feature data, and report the abnormality identifier in correspondence with the information of the operating system.

[0040] In this embodiment, the exception identifier can identify the exceptions that occur in the operating system. To this end, the exception identifier and the operating system information can be reported accordingly, so that the server that receives the report can perform statistical analysis on the exceptions that occur in the operating system based on the operating system information and the exception identifier.

[0041] In this embodiment, the reported exception information can be received by the server, and the server can determine the root cause of the exception based on the exception reporting information, and then the server can determine and send the exception solution corresponding to the exception. Of course, the reported exception information can also be received by other devices, which is not a limitation of this application.

[0042] See also Figure 1B The following is an illustrative example of the solution of this embodiment through a specific usage scenario.

[0043] In this embodiment, the device where the operating system is located is temporarily set as a terminal.

[0044] In this embodiment, the operating system can be monitored through the exception monitoring process. If an operating system exception is detected, the operating system exception backtracking information is obtained and stored in the memory. At the same time, the operating system information can also be obtained.

[0045] After obtaining the exception traceback information, the exception reporting process can filter out interference information and perform feature extraction to obtain exception feature data. The exception reporting process can then generate an exception identifier based on the exception feature data to identify the exception and report the exception identifier and operating system information to the server.

[0046] The server can perform operating system-based abnormal statistics and display based on the obtained reports.

[0047] In this embodiment, exception backtracing information of the operating system where the exception occurs and information about the operating system are obtained, and information about the process in which the exception occurs in the operating system can be obtained through the obtained backtracing information; interference information in the exception backtracing information is filtered, and information that interferes with the process of determining the exception in the exception backtracing information can be filtered out, and then feature extraction is performed on the filtered exception backtracing information to obtain exception feature data, which can characterize core information of the exception process. Thus, an exception identifier for identifying the exception is generated based on the exception feature data, and the exception identifier is reported in correspondence with the information of the operating system, ensuring that the reported information can accurately identify the exception that has occurred for statistical purposes.

[0048] The exception handling method provided in the embodiment of the present application can be executed by any device with data processing capabilities, such as the hardware device where the operating system is located, and also such as servers, mobile terminals (such as mobile phones, PADs, etc.) and PCs, Internet of Things devices (IOT), etc.

[0049] Example 2

[0050] Figure 2A FIG. 1 is a flowchart of a method for handling an exception according to the second embodiment of the present invention; FIG. Figure 2A As shown, it includes:

[0051] S201: Monitor the abnormality of the operating system.

[0052] For specific monitoring methods, please refer to relevant technologies and will not be described in detail here.

[0053] S202: If an operating system abnormality is detected, determine whether the operating system continues to work.

[0054] If the operating system continues to work, step S203 is executed; if the operating system does not continue to work, it is determined that the operating system is restarted, and step S204 is executed.

[0055] In this embodiment, the operating system includes an operating system, and an operating system is generally divided into a kernel state and a user state.

[0056] Kernel state runs OS (operating system) kernel-level privileged code, manages and controls access to various hardware, and is the cornerstone of the entire system.

[0057] User mode runs non-privileged code of various application software (such as applications). Exceptions in non-core applications generally do not endanger the normal operation of the entire system, that is, generally do not cause a restart.

[0058] Determine whether the software is operating normally, that is, determine whether the operating system in the operating system is restarted. If it is restarted, it will restart. If the exception generally occurs in kernel mode, it may cause a restart; if the exception occurs in user mode, it generally does not cause a restart. Restarting in this embodiment refers to restarting the operating system included in the operating system.

[0059] Taking the Linux system as an example, if an exception occurs in the kernel state (generally called panic), it may trigger the Linux kernel to enter the exception handler, and may eventually trigger the Linux system to restart.

[0060] If an exception occurs in an application software in user mode, the kernel will send a related signal to the corresponding process. The process responds to the signal and executes the corresponding signal handler, which may eventually cause the process corresponding to the application software to be terminated, resulting in the exit of the application software, but the possibility of causing the system to restart is small.

[0061] S203: Acquire the exception backtrace information according to the signal processing program executed correspondingly when an exception occurs in the operating system.

[0062] After step S203 is completed, step S205 is continued.

[0063] A signal handler is a program that is registered by a process through a function such as sigaction() and executed when a signal is received. If a signal handler is not registered, the system default handler is used.

[0064] Specifically, please refer to Figure 2B , showing a flow chart for generating and responding to signals. After an exception occurs, step 1 can be executed: the kernel sends a signal to the main program that triggered the exception, terminating the process's execution flow. Then, step 2 can be executed: the kernel calls back the signal handler that the process registered in advance. Step 3 then executes the signal handler (i.e., the code or signal handler is executed). After step 3 is completed, step 4 continues: the program resumes at the point of interruption, returning to the point where the exception terminated.

[0065] In this embodiment, after the kernel calls back the signal handler signalhandler registered in advance by the process, a processing logic for obtaining the exception backtrace information can be added before the signal handler starts to be executed.

[0066] In this embodiment, the exception backtrace information is obtained through a signal processing program (single), and there is no need to separately define a function or program for obtaining function call information, nor is there a need to mirror all information before obtaining the exception backtrace information. The emergency processing performed after the exception is generated can be directly started and backtraced to directly obtain the exception backtrace information, which is simple and convenient to implement.

[0067] Optionally, in this embodiment, obtaining exception backtrace information of the operating system where the exception occurs includes: obtaining function call information with the exception occurrence point as the end point, wherein the function call information includes the called function name and the corresponding function call address.

[0068] Typically, a function generally corresponds to a function name and a function call address, that is, the corresponding function can be determined and called through the function call address. Then, the function call address can be used as a unique identifier of the called function.

[0069] The function call information includes multiple functions, which can be called sequentially in the order from front to back in the function call information. The last function called corresponds to the point where the exception occurred, which serves as the endpoint. The function call information can specifically be a function call chain. It should be understood that the above is for illustrative purposes only and is not intended to limit the present application.

[0070] The exception occurrence point can be the time point corresponding to the exception occurrence, or it can be a function called in the function call information at the time of the exception occurrence. By obtaining the function call information ending at the exception occurrence point, it is possible to determine the function call situation before the exception occurred, that is, the historical trace corresponding to the exception occurrence.

[0071] In this embodiment, since the function call information with the exception occurrence point as the end point can be regarded as the historical trace corresponding to the exception occurrence, the function called when the exception occurs can be analyzed through the function call information, so that the exception feature data determined therefrom corresponds to the function that causes the exception, so as to improve the exception identification determined based on the exception feature data to more accurately identify the exception that has occurred.

[0072] Specifically, in this embodiment, step S203 includes:

[0073] terminating the abnormal thread corresponding to the exception; performing a backtrace operation on the stack corresponding to the abnormal thread by calling the signal processing program and taking the calling point of the signal processing program as the starting point to obtain original backtrace information; and determining the function call information based on the original backtrace information.

[0074] Specifically, after the signal handler is called, the stack corresponding to the abnormal thread can be backtracked with the calling point of the signal handler as the starting point to obtain the original backtracking information. After saving the original backtracking information, the exception handler can be continued to be executed. Figure 2B Step 3 is shown.

[0075] In addition, after obtaining the original backtrace information, the signal handler-related information can be directly removed. Compilation options can then be added to the original backtrace information to obtain symbol information. To reduce the file size after adding compilation options, in this embodiment, it is preferred to add the -funwind-tables compilation option to obtain basic symbol information.

[0076] Then, the function call information with the exception occurrence point as the end point can be determined based on the obtained symbol information.

[0077] It should also be noted that in this embodiment, since a backtrace operation is performed on the stack corresponding to the exception thread, starting from the call point of the signal handler to obtain the original backtrace information, the order of functions in the original backtrace information is opposite to the order in which the functions were actually called. Therefore, among the functions determined based on the backtrace information, the point at which the exception occurred may correspond to the first function. In this embodiment, the order of the functions in the determined backtrace information may be reversed, or no processing may be performed, which is not limited in this embodiment.

[0078] S204: After the operating system is restarted, obtain crash information of the operating system from the memory, and obtain exception backtrace information from the crash information.

[0079] After step S204 is completed, step S205 is continued.

[0080] In this embodiment, if the system crashes, the system will store the information before the crash (such as function call information, values ​​in registers, etc.) as crash information in the memory in advance. Therefore, in this embodiment, after the system is restarted, the crash information of the operating system can be obtained from the memory, and the exception backtrace information can be obtained from the crash information.

[0081] Specifically, taking the Linux system as an example, when the Linux kernel is abnormal, the panic process will be triggered. At this time, the file system cannot be accessed. The panic process can store the panic information (crash information) in the memory. After restarting, the panic information can be obtained from the memory, and the abnormal backtrace information can be determined based on the obtained panic information.

[0082] In addition, taking a real-time operating system (RTOS) as an example, when an exception occurs in the RTOS system, the last word before the exception occurs can be stored in the memory as crash information, so that the crash information can be obtained from the memory after the real-time operating system (RTOS) is restarted.

[0083] S205: Filter the interference information in the abnormal backtracking information, and extract features from the filtered abnormal backtracking information to obtain abnormal feature data.

[0084] Optionally, the function call information includes call information for a dynamic library function, and the function call address includes a floating address of a dynamic library file to which the dynamic library function belongs and a relative address of the dynamic library function within the dynamic library file. In this embodiment, due to the security feature ASLR (Address space layout randomization) of the dynamic library file, the address of the loaded dynamic library file is a changing floating address, which further causes the call address of the dynamic library function to also change. Since the address of the dynamic library file is a floating address, the address of the dynamic library file will interfere with the process of determining the exception. To this end, in the present application, the interference information in the exception backtrace information is filtered, including: filtering the floating address of the dynamic library file included in the function call information. After filtering, the relative address of the dynamic library function within the dynamic library file will remain, and the relative address in the dynamic library file will not change, so that the called function can be accurately identified, thereby ensuring the accuracy of the exception identification obtained in the subsequent steps.

[0085] In this embodiment, after filtering out the floating addresses of the dynamic library files, feature extraction may be performed on the function call information, and the obtained abnormal feature data may be the core function call information during the abnormality occurrence process.

[0086] S206: Calculate the abnormal feature data using an information digest algorithm to obtain an abnormality identifier for identifying the abnormality.

[0087] In this embodiment, the information digest algorithm may specifically be an MD5 algorithm, etc., which is not limited in this embodiment.

[0088] Since the calling address of a function can be used as an identifier of the called function, after calculation using a digest algorithm, an exception identifier (crash ID) for identifying the exception that occurred can be obtained.

[0089] S207: Report the abnormality identifier and the operating system information in correspondence.

[0090] Optionally, in this embodiment, step S207 may include: generating reporting information based on the exception identifier, information of the operating system and the function call information; reporting the reporting information to the server so that the server can locate the exception occurring in the operating system based on the reporting information.

[0091] Specifically, the server can reproduce the process of the exception occurrence in the corresponding operating system based on the function call information to locate the exception.

[0092] Furthermore, reporting information is generated based on at least one of the time when the exception occurs, the name of the process where the exception occurs, the name of the thread where the exception occurs, and the register value when the exception occurs, as well as the exception identifier, the operating system information and the function call information.

[0093] In this embodiment, the time when the exception occurs, the name of the process where the exception occurs, the name of the thread where the exception occurs, the register value when the exception occurs, etc. can be used to assist in locating the exception.

[0094] The steps in this embodiment can all be executed by the device where the operating system is located.

[0095] In this embodiment, if an exception of the operating system is monitored, the exception backtrace information of the operating system where the exception occurred and the information of the operating system are obtained. The information of the process in which the exception occurred in the operating system can be obtained through the obtained backtrace information; the interference information in the exception backtrace information is filtered, and the information that interferes with the process of determining the exception in the exception backtrace information can be filtered out, and then the filtered exception backtrace information is subjected to feature extraction to obtain exception feature data. The exception feature data can characterize the core information of the exception process. Thus, an exception identifier for identifying the exception is generated based on the exception feature data, and the exception identifier is reported corresponding to the information of the operating system, ensuring that the reported information can accurately identify the exception that has occurred for statistical purposes. The exception is an important factor affecting the stability of the operating system. By performing statistics on the exception, effective monitoring of the stability of the operating system can be further achieved, and the exception can be located based on the function call information in the reported information, thereby determining an effective exception solution for the exception and repairing the exception of the operating system.

[0096] The exception handling method provided in the embodiment of the present application can be executed by any device with data processing capabilities, such as the hardware device where the operating system is located, and also such as servers, mobile terminals (such as mobile phones, PADs, etc.) and PCs, Internet of Things devices (IOT), etc.

[0097] Example 3

[0098] Figure 3 FIG. 1 is a flowchart of a method for handling an exception according to Embodiment 3 of the present invention; FIG. Figure 3 As shown, it includes:

[0099] S301: Acquire operating system exception information reported by multiple terminals.

[0100] The abnormal information includes: operating system information and an abnormality identifier of the abnormality, and the abnormality identifier is generated based on abnormal feature data obtained by filtering interference information and extracting features from abnormal backtracking information of the operating system.

[0101] The specific content of the reported abnormal information can be referred to the above embodiment, and will not be repeated in this embodiment.

[0102] In this embodiment, reports from all terminals may be received through one server; or reports from terminals may be received separately through multiple servers. For example, a server may correspond to an operating system one-to-one, which is not limited in this embodiment.

[0103] S302: Perform operating system-based abnormality statistics on the plurality of terminals according to the operating system information and the abnormality identifier.

[0104] The abnormality statistics based on the operating system may be to count the number of abnormality identifiers corresponding to each operating system.

[0105] Since there may be different operating systems and different exceptions that occur, but the generated exception identifiers are the same, in this embodiment, exception statistics based on the operating system are performed to ensure the accuracy of the statistical results.

[0106] Optionally, in this embodiment, if the exception information also includes function call information when the exception occurs, the method may further include: locating the exception occurring in the operating system based on the information of the operating system and the function call information included in the exception information.

[0107] In this embodiment, the server can obtain the exception report information. The staff can locate the exception based on the function call information in the exception report information, determine the root cause of the exception, and further determine the corresponding repair data, which can then be sent to the operating system. This will repair the operating system exception by upgrading the operating system and minimize the recurrence of the same type of exception.

[0108] Optionally, in this embodiment, step S302 may include: based on the information of the operating system, counting the abnormal identifiers in the abnormal information reported by the multiple terminals, and obtaining statistical data of abnormalities occurring in different operating systems to make the statistical results more intuitive.

[0109] Obtaining statistical data on abnormalities occurring in different operating systems may, for example, obtain abnormality identifiers corresponding to multiple operating systems and the number of times each abnormality identifier is reported, so as to make the statistical results more intuitive.

[0110] Optionally, in this embodiment, the method may further include: performing analysis based on abnormal statistics of the operating system; and determining whether to generate alarm information corresponding to the operating system based on the analysis result.

[0111] For example, the total number of crashes and the crash rate can be monitored; or, statistics can be classified by crash ID or monitored by device, etc. Alarms can be issued based on the monitoring results and preset conditions. The preset conditions can be appropriately set by those skilled in the art based on actual conditions, such as when the number of crashes reaches a certain threshold, or when the crash rate reaches a certain threshold, etc.

[0112] In this embodiment, abnormal information of operating system abnormalities reported by multiple terminals is obtained, wherein the abnormal information includes: information of the operating system and an abnormal identifier of the abnormality, and the abnormal identifier is generated based on abnormal feature data obtained after interference information filtering and feature extraction of abnormal backtracking information of the operating system; based on the information of the operating system and the abnormal identifier, operating system-based abnormality statistics are performed on the multiple terminals. Since the abnormal identifier can be used to identify abnormalities occurring in the operating system, the embodiment of the present application can accurately count the abnormalities reported by the terminals based on the abnormal identifier based on the operating system. The abnormality is an important factor affecting the stability of the software system. By accurately counting the abnormalities, the stability of the operating system can be monitored.

[0113] The exception handling method provided in the embodiment of the present application can be executed by any device with data processing capabilities, such as a server.

[0114] Example 4

[0115] Figure 4A FIG. 4 is a flowchart of a method for handling an exception according to a fourth embodiment of the present invention; FIG. Figure 4A As shown, it includes:

[0116] S401: If an abnormality of the terminal operating system is detected, the abnormality information is obtained.

[0117] This step can be performed by the device.

[0118] The exception information in this step may include exception backtrace information and other exception-related information, and may also include operating system information.

[0119] Exceptions occurring on different operating systems (OSs) or at different levels of code (e.g., kernel mode or user mode) ultimately behave differently and are handled differently. Accordingly, the methods for obtaining exception information, and therefore crashreport files, also vary. The following categorizes these differences.

[0120] In this embodiment, the crashreport file includes function call information with the exception occurrence point as the end point, exception identification generated after interference information filtering and feature extraction based on the function call information, and operating system information. The crashreport file can also include exception parameter information, such as the time when the exception occurred, the name of the process that generated the exception, the name of the thread that generated the exception, the register value when the exception occurred, etc.

[0121] The following describes several methods for obtaining function call information:

[0122] (1) Process exception (i.e., the exception occurs in user mode)

[0123] In one case, when a process exception is detected, the kernel calls the corresponding process for processing. For example, when a process in a Linux system is abnormal, it can be processed with the help of a signal mechanism (calling a signal handler through the kernel).

[0124] A processing process using the signal mechanism may include:

[0125] (1) When a process exception occurs, the kernel sends a related signal to the process that triggered the exception; (2) The kernel calls back the signal handler that the process registered in advance; (3) The signal handler is executed; (4) The program returns to the place where it was terminated abnormally and continues execution.

[0126] In practice, it's necessary to register handlers for signals related to software exceptions, including SIGILL, SIGBUS, SIGSEGV, SIGABRT, and SIGFPE. Other signals can be handled by the kernel's default handlers. A signal handler is a program that a process registers through a function like sigaction() and executes when it receives a signal.

[0127] By adding backtrace logic at the beginning of this program, the stack backtrace of this exception can be obtained to determine the function call information.

[0128] In this embodiment, the original backtrace information can be obtained through stack backtrace. Then, the stack backtrace of the current exception can be obtained in the signal handler using the functions of the compiler tool chain and the basic C library, such as the backtrace() series functions of gcc-glibc. However, this is not limited to this. It should be understood by those skilled in the art that other appropriate methods can also be used to obtain the stack backtrace of the current exception. For example, the stack backtrace library, such as libunwind, can be used to obtain the stack backtrace of the current exception.

[0129] When using the backtrace() family of functions from gcc-glibc, you first need the glibc stack backtrace function.

[0130] Among them, glibc can use the following functions to implement stack backtrace:

[0131] A, int backtrace(void**buffer,int size) / / Import the stack backtrace original information of the signal handler call point into buffer;

[0132] B, char**backtrace_symbols(void*const*buffer, int size)

[0133] / / The backtrace information in the buffer is displayed more user-friendly after symbol parsing. This function needs to allocate memory with malloc. If a memory exception occurs when the exception occurs, or if malloc is in progress, a deadlock may occur because the lock is held during malloc.

[0134] C, void backtrace_symbols_fd(void*const*buffer,int size,int fd) / / Write the backtrace information with symbols to the file represented by fd. This function does not require malloc to allocate memory.

[0135] Typically, when a single process crashes (abnormally), the operating system can still operate normally. Therefore, the crashreport is stored in the file system through the backtrace_symbols_fd() method mentioned above and uploaded to the server for monitoring. For example, the crashreport file can be named / data / crash_reports / crash_report_xx, where xx rotates between 00 and 09 to store up to the last 10 crashes.

[0136] Based on the acquired stack traceback information, it is not possible to directly determine the function call information ending at the point where the exception occurred. It is necessary to determine the symbol information therein, which requires compiler options. Specifically, the -g compiler option or the -funwind-tables compiler option can be added to the original traceback information. It should be understood that in order to reduce the file size after adding the compiler options, the -funwind-tables compiler option is preferred.

[0137] By adding the -funwind-tables compilation option, we obtain basic symbol information. Furthermore, we use addr2line and a binary object file with sufficient symbol information (compiled with the -g option) to locate the source code line in the call backtrace, thereby determining the called function corresponding to the exception occurrence point and obtaining function call information ending at the exception occurrence point.

[0138] (2) Kernel exception

[0139] Taking Linux as an example, kernel exceptions often trigger a panic process, often leading to a system reboot. Because the kernel is in an uncertain state during a panic and unable to access the file system, panic information is stored in pre-reserved memory. After a reboot (without power outage), the panic information can be retrieved from this reserved memory.

[0140] In one feasible approach, panic information can be stored through the ram-console. After the system is restarted, the panic information can be obtained through / proc / last_kmsg. Based on the panic information, the function call information ending at the point where the exception occurred can be determined. Exception parameter information such as the register values ​​before the system restart can also be determined.

[0141] In another feasible approach, panic information can be implemented and obtained based on pstore.

[0142] (3) RTOS panic

[0143] RTOS systems also restart when an exception occurs. The resulting panic information is stored in the / data / crash_reports / crash_report_xx file after the restart. After the restart, you can directly retrieve the panic information from the / data / crash_reports / crash_report_xx file. This information can be used to identify the function calls that terminated at the point of the exception. It can also be used to determine abnormal parameter information, such as register values ​​before the system restarted.

[0144] In this embodiment, an information acquisition solution applicable to different systems is provided, so that after the abnormality reporting information is subsequently sent to the server, the server can perform cross-system abnormality monitoring.

[0145] In this embodiment, after the function call information is obtained, interference information filtering and feature extraction can be performed, and an abnormality identifier for identifying an abnormality can be obtained, and the abnormality identifier and operating system information can be reported.

[0146] In addition, in this embodiment, Figure 4B As shown, the terminal may include an exception monitoring process crash catcher, which is used to detect the occurrence of a crash and generate and store relevant crash reports. The crash report format varies depending on the Linux / RTOS.

[0147] To categorize and count crashes, this embodiment generates an exception identifier based on the exception traceback information in the crash report, namely, the function call information ending at the crash point. This function call information reflects the core information of the crash. Based on this function call information, noise information filtering and feature extraction are performed to obtain the abnormal feature data that represents the crash.

[0148] Taking the crash report generated by a process crash on Linux as an example, each line in the exception backtrace represents a function call. These lines are combined to generate the exception signature data, and their MD5 value is calculated. The resulting MD5 value uniquely identifies the crash. In this embodiment, this MD5 value is called the crashID, or exception identifier. Using the exception identifier, we can accurately deduplicate exceptions, ensuring the accuracy of statistical results.

[0149] It's important to note that in Linux processes, if function call information involves a dynamic library file, and the dynamic library file is often loaded into a different memory address each time due to the security feature ASLR (Address Space Layout Randomization), then even for the same type of crash, the floating address of the dynamic library file will not be the same on different machines, or on different boots of the same machine, and the crashID calculated using the above method will also be different. However, while the floating address of the dynamic library file is not fixed, the relative address of the dynamic library function within the dynamic library file is fixed. Therefore, the floating address can be filtered out as noise information, and only the relative address is retained to ensure the accuracy of the crashID.

[0150] S402: Report abnormal information to the server.

[0151] like Figure 4B As shown, the terminal can also take out the crashreport and report it to the server through the exception reporting process crash reporter, that is, report the exception.

[0152] S403: The server performs abnormal monitoring statistics and alarms based on the reported information from the terminal.

[0153] This step can be performed by the server or other terminal that receives the abnormality reporting information.

[0154] like Figure 4B As shown, the server may include an exception database crash database and an exception process statistics and monitoring module crash statistics & monitor. A process for monitoring exception information crash may include:

[0155] A. Store crash reports on the server side through the crash database.

[0156] B. Use crash statistics & monitor to analyze server-side crash report data and monitor alarms.

[0157] For example, the total number of crashes and the crash rate can be monitored; or, statistics can be classified by crash ID or monitored by device, etc. Alarms can be issued based on the monitoring results and preset conditions. The preset conditions can be appropriately set by those skilled in the art based on actual conditions, such as when the number of crashes reaches a certain threshold, or when the crash rate reaches a certain threshold, etc.

[0158] Crash rate = number of crashes per day for the product / number of active machines for the product per day. When the actual crash rate exceeds this threshold, an alarm is triggered, and the responsible person is notified via email, etc.

[0159] Through this embodiment, if an anomaly of the operating system is monitored, the anomaly backtrace information of the operating system where the anomaly occurs and the information of the operating system are obtained, and the information of the process in which the anomaly occurs in the operating system can be obtained through the obtained backtrace information; the interference information in the anomaly backtrace information is filtered, and the information that interferes with the process of determining the anomaly in the anomaly backtrace information can be filtered out, and then the filtered anomaly backtrace information is subjected to feature extraction to obtain anomaly feature data, and the anomaly feature data can characterize the core information of the anomaly process, thereby generating an anomaly identifier for identifying the anomaly based on the anomaly feature data, and reporting the anomaly identifier in correspondence with the information of the operating system, thereby ensuring that the reported information can accurately identify the anomaly that has occurred, thereby ensuring the accuracy of the anomaly statistical results.

[0160] The exception handling method provided in the embodiment of the present application can be executed by any device with data processing capabilities, such as the hardware device where the operating system is located, and also such as servers, mobile terminals (such as mobile phones, PADs, etc.) and PCs, Internet of Things devices (IOT), etc.

[0161] Example 5

[0162] Figure 5 1 is a schematic diagram of the structure of an exception handling device according to an embodiment of the present invention; as shown in the figure, the exception handling device includes:

[0163] An information acquisition module 501 is used to acquire the exception backtrace information of the operating system where the exception occurs and information about the operating system;

[0164] A feature acquisition module 502 is configured to filter interference information in the abnormal backtracking information and perform feature extraction on the filtered abnormal backtracking information to obtain abnormal feature data;

[0165] The reporting module 503 is configured to generate an abnormality identifier for identifying the abnormality according to the abnormality feature data, and report the abnormality identifier in correspondence with the information of the operating system.

[0166] Optionally, in this embodiment, the information acquisition module is specifically used to: acquire function call information with the exception occurrence point as the end point, wherein the function call information includes the called function name and the corresponding function call address.

[0167] Optionally, in this embodiment, the function call information includes call information of a dynamic library function, and the function call address includes a floating address of a dynamic library file to which the dynamic library function belongs and a relative address of the dynamic library function within the dynamic library file; the feature acquisition module includes a filtering module for filtering the floating address of the dynamic library file included in the function call information.

[0168] Optionally, in this embodiment, the reporting module includes: a reporting information generation module, used to generate reporting information based on the exception identifier, the information of the operating system and the function call information; a sending module, used to report the reporting information to the server, so that the server can locate the exception occurring in the operating system based on the reporting information.

[0169] Optionally, in this embodiment, the reporting information generation module is specifically used to generate reporting information based on at least one of the time when the exception occurred, the name of the process where the exception occurred, the name of the thread where the exception occurred, and the register value when the exception occurred, as well as the exception identifier, the operating system information and the function call information.

[0170] Optionally, in this embodiment, the information acquisition module is specifically configured to acquire the exception backtrace information according to a signal processing program executed when the operating system exception occurs, if an exception is detected in the operating system.

[0171] Optionally, in this embodiment, the reporting module includes an identification generation module, which is used to calculate the abnormal feature data through an information digest algorithm to obtain an abnormality identification for identifying the abnormality.

[0172] In this embodiment, exception backtracing information of the operating system where the exception occurs and information about the operating system are obtained, and information about the process in which the exception occurs in the operating system can be obtained through the obtained backtracing information; interference information in the exception backtracing information is filtered, and information that interferes with the process of determining the exception in the exception backtracing information can be filtered out, and then feature extraction is performed on the filtered exception backtracing information to obtain exception feature data, which can characterize core information of the exception process. Thus, an exception identifier for identifying the exception is generated based on the exception feature data, and the exception identifier is reported in correspondence with the information of the operating system, ensuring that the reported information can accurately identify the exception that has occurred for statistical purposes.

[0173] Example 6

[0174] Figure 6 This is a schematic diagram of the structure of an exception handling device according to an embodiment of the present invention; as shown in the figure, it includes:

[0175] The exception information acquisition module 601 is used to obtain exception information of operating system exceptions reported by multiple terminals, wherein the exception information includes: operating system information and an exception identifier of the exception, and the exception identifier is generated based on the exception feature data obtained by filtering interference information and extracting features from the abnormal backtrace information of the operating system;

[0176] The statistics module 602 is configured to perform operating system-based anomaly statistics on the plurality of terminals according to the operating system information and the anomaly identifier.

[0177] Optionally, in this embodiment, if the exception information also includes function call information when the exception occurs, the device also includes: an exception locating module, which is used to locate the exception occurring in the operating system based on the information of the operating system and the function call information included in the exception information.

[0178] Optionally, in this embodiment, the statistical module is specifically configured to: based on information of the operating system, perform statistics on the abnormality identifiers in the abnormality information reported by the plurality of terminals to obtain statistical data of abnormalities occurring in different operating systems.

[0179] In this embodiment, abnormal information of operating system abnormalities reported by multiple terminals is obtained, wherein the abnormal information includes: information of the operating system and an abnormal identifier of the abnormality, and the abnormal identifier is generated based on abnormal feature data obtained after interference information filtering and feature extraction of abnormal backtracking information of the operating system; based on the information of the operating system and the abnormal identifier, operating system-based abnormality statistics are performed on the multiple terminals. Since the abnormal identifier can be used to identify abnormalities occurring in the operating system, the embodiment of the present application can accurately count the abnormalities reported by the terminals based on the abnormal identifier based on the operating system. The abnormality is an important factor affecting the stability of the software system. By accurately counting the abnormalities, the stability of the operating system can be monitored.

[0180] Example 7

[0181] Reference Figure 7 , shows a schematic structural diagram of an electronic device according to embodiment 7 of the present invention. The specific embodiment of the present invention does not limit the specific implementation of the electronic device.

[0182] like Figure 7 As shown, the electronic device may include: a processor (processor) 702 , a communication interface (Communications Interface) 704 , a memory (memory) 706 , and a communication bus 708 .

[0183] in:

[0184] The processor 702 , the communication interface 704 , and the memory 706 communicate with each other via a communication bus 708 .

[0185] The communication interface 704 is used to communicate with other electronic devices or servers.

[0186] The processor 702 is configured to execute the program 710 , and specifically may execute the relevant steps in the above-mentioned exception handling method embodiment.

[0187] Specifically, the program 710 may include program codes, which include computer operation instructions.

[0188] Processor 702 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The one or more processors included in a smart device may be processors of the same type, such as one or more CPUs, or processors of different types, such as one or more CPUs and one or more ASICs.

[0189] The memory 706 is used to store the program 710. The memory 706 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0190] The specific implementation of each step in program 710 can refer to the corresponding description of the corresponding steps and units in the above-mentioned exception handling method embodiment, and has corresponding effects, which will not be repeated here.

[0191] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present invention can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present invention.

[0192] The above-mentioned method according to the embodiment of the present invention can be implemented in hardware, firmware, or be implemented as software or computer code that can be stored in recording medium (such as CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or be implemented by the original storage downloaded by network in remote recording medium or non-temporary machine-readable medium and will be stored in the computer code in local recording medium, so that the method described herein can be stored in such software processing on the recording medium using general-purpose computer, special-purpose processor or programmable or special-purpose hardware (such as ASIC or FPGA).It is understood that computer, processor, microprocessor controller or programmable hardware include storage components (such as, RAM, ROM, flash memory etc.) that can store or receive software or computer code, when described software or computer code is accessed and executed by computer, processor or hardware, implementation exception handling method described herein.In addition, when general-purpose computer accesses the code for realizing the exception handling method shown here, the execution of code converts general-purpose computer into the special-purpose computer for executing the exception handling method shown here.

[0193] Those skilled in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present invention.

[0194] The above implementation methods are only used to illustrate the embodiments of the present invention, and are not intended to limit the embodiments of the present invention. Ordinary technicians in the relevant technical field may make various changes and modifications without departing from the spirit and scope of the embodiments of the present invention. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of the present invention, and the scope of patent protection of the embodiments of the present invention should be defined by the claims.

Claims

1. An exception handling method, comprising: Obtaining exception backtrace information of the operating system where the exception occurred and information about the operating system; filtering interference information in the abnormal backtrace information, and performing feature extraction on the filtered abnormal backtrace information to obtain abnormal feature data, wherein the interference information at least includes a floating address that interferes with the process of determining the abnormality; generating an abnormality identifier for identifying the abnormality according to the abnormality feature data, and reporting the abnormality identifier in correspondence with information of the operating system; The obtaining of the exception backtrace information of the operating system where the exception occurs includes: determining whether the operating system continues to work; if the operating system continues to work, obtaining the exception backtrace information according to a signal processing program executed when the operating system has an exception.

2. The method according to claim 1, wherein The obtaining of the exception backtrace information of the operating system where the exception occurs includes: Acquire function call information with the exception occurrence point as the end point, wherein the function call information includes the called function name and the corresponding function call address.

3. The method according to claim 2, wherein: The function call information includes call information of a dynamic library function, and the function call address includes a floating address of a dynamic library file to which the dynamic library function belongs and a relative address of the dynamic library function within the dynamic library file; The filtering of interference information in the abnormal backtracking information includes: The floating address of the dynamic library file included in the function call information is filtered.

4. The method according to claim 2, wherein: Reporting the abnormality identifier and the operating system information in correspondence includes: Generate reporting information according to the exception identifier, the operating system information and the function call information; The reported information is reported to a server, so that the server can locate the abnormality occurring in the operating system according to the reported information.

5. The method according to claim 4, wherein The generating of reporting information according to the exception identifier, the operating system information, and the function call information further includes: Report information is generated based on at least one of the time when the exception occurs, the name of the process where the exception occurs, the name of the thread where the exception occurs, and the register value when the exception occurs, as well as the exception identifier, the operating system information, and the function call information.

6. The method according to claim 1, wherein The obtaining of the exception backtrace information of the operating system where the exception occurs includes: If an exception is detected in the operating system, the exception backtrace information is obtained according to a signal processing program executed when the exception occurs in the operating system.

7. The method according to claim 1, wherein Generating an abnormality identifier for identifying the abnormality according to the abnormality feature data includes: The abnormal feature data is calculated using an information digest algorithm to obtain an abnormality identifier for identifying the abnormality.

8. An exception handling method, comprising: Obtaining exception information of operating system exceptions reported by multiple terminals, wherein the exception information includes: operating system information and an exception identifier of the exception, the exception identifier being generated based on exception feature data obtained by filtering interference information and extracting features from exception backtrace information of the operating system, wherein the interference information at least includes a floating address that interferes with a process of determining the exception; the exception backtrace information is obtained based on a signal processing procedure executed corresponding to the occurrence of the operating system exception while the operating system continues to operate; According to the information of the operating system and the abnormality identifier, operating system-based abnormality statistics are performed on the plurality of terminals.

9. The method according to claim 8, wherein If the exception information also includes function call information when the exception occurs, the method further includes: The exception occurring in the operating system is located according to the operating system information and the function call information included in the exception information.

10. The method according to claim 9, wherein: The performing operating system-based abnormality statistics on the plurality of terminals according to the operating system information and the abnormality identifiers includes: Based on the information of the operating system, the abnormal identifiers in the abnormal information reported by the multiple terminals are counted to obtain statistical data of abnormalities occurring in different operating systems.

11. An exception handling device, comprising: An information acquisition module, configured to acquire exception backtracking information of the operating system where the exception occurred and information about the operating system; a feature acquisition module, configured to filter interference information in the abnormal backtrace information and perform feature extraction on the filtered abnormal backtrace information to obtain abnormal feature data, wherein the interference information at least includes a floating address that interferes with the process of determining the abnormality; a reporting module, configured to generate an abnormality identifier for identifying the abnormality according to the abnormality feature data, and report the abnormality identifier in correspondence with information of the operating system; The information acquisition module acquires the exception backtrace information of the operating system where the exception occurs, including: determining whether the operating system continues to work; if the operating system continues to work, acquiring the exception backtrace information according to a signal processing program executed when the operating system has an exception.

12. An exception handling device, comprising: An exception information acquisition module is configured to acquire exception information of operating system exceptions reported by multiple terminals, wherein the exception information includes: operating system information and an exception identifier of the exception, wherein the exception identifier is generated based on exception feature data obtained by filtering interference information and extracting features from the operating system's exception backtrace information, wherein the interference information at least includes a floating address that interferes with the process of determining the exception; the exception backtrace information is obtained based on a signal processing program executed corresponding to the operating system exception when the operating system continues to operate; The statistics module is used to perform operating system-based anomaly statistics on the plurality of terminals according to the operating system information and the anomaly identifier.

13. An electronic device comprising: A processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute an operation corresponding to the exception handling method according to any one of claims 1 to 10.

14. A computer storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the exception handling method according to any one of claims 1 to 10 is implemented.

Images