Anomaly log collection method, device, equipment, medium and program product

By suspending the abnormal process in the Android system and creating a target storage path, the system continuously collects and displays abnormal logs, solving the problems of large log volume and a lot of useless logs, and improving the efficiency of abnormal location and system stability.

CN115563070BActive Publication Date: 2026-07-10HAINING ESWIN IC DESIGN CO LTD +1

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
HAINING ESWIN IC DESIGN CO LTD
Filing Date
2022-10-14
Publication Date
2026-07-10

AI Technical Summary

Technical Problem

In the current technology for collecting exception logs in the Android system, the log content is huge and there are many useless logs, which makes it difficult for developers to quickly locate exceptions, and the system is not robust enough, which can easily cause other exceptions due to chain reactions.

Method used

When an exception is captured, the exception process is suspended, a target storage path is created, and related exception logs are continuously collected before the process terminates, including determining the exception level and sequence number. Different types of logs are selectively copied to the target storage path and packaged into a compressed file for display.

Benefits of technology

It improves the effectiveness and collection efficiency of exception logs, helping developers quickly locate exceptions, protect the scene where exceptions occur, and reduce the impact of chain reactions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115563070B_ABST
    Figure CN115563070B_ABST
Patent Text Reader

Abstract

Embodiments of the present application provide a method, device, equipment, medium and program product for collecting abnormal logs, relating to the field of software development. The method comprises: when a to-be-handled abnormality is captured, suspending an abnormal process corresponding to the to-be-handled abnormality; creating a target storage path according to the to-be-handled abnormality, and canceling the suspension of the abnormal process; and continuously collecting target abnormal logs associated with the to-be-handled abnormality based on the target storage path until the abnormal process terminates running. The method for collecting abnormal logs provided by the embodiments of the present application can improve the effectiveness and collection efficiency of the collected logs, and based on this, assist developers to quickly locate the abnormality, so as to locate the problems existing in the code.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of software development, and more specifically, to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for collecting exception logs. Background Technology

[0002] Currently, when an exception occurs, developers typically rely on the native exception handling module provided by the Android system to collect and analyze exception information. Additionally, to collect more effective exception logs for analysis, the common practice is to save logs generated from the moment the Android system boots up, or to save all logs generated in real time. Then, based on the saved logs, exceptions are located and analyzed by searching for keywords in the logs.

[0003] However, while this approach ensures the completeness of the logs used for analysis, the sheer volume of logs is overwhelming. In particular, a large amount of these logs contains a significant amount of irrelevant information, which clearly hinders developers from quickly locating anomalies. Furthermore, Android systems also contain some less obvious exception logs that are easily overlooked by developers. Moreover, the lack of protection over the exception's occurrence context allows the system to become less robust, leading to a chain reaction of other exceptions after the initial one, further complicating the anomaly identification process for developers. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, electronic device, computer-readable storage medium, and computer program product for collecting exception logs, in order to solve one of the aforementioned technical problems. To achieve this purpose, the embodiments of this application provide the following technical solutions.

[0005] On the one hand, embodiments of this application provide a method for collecting exception logs, the method comprising:

[0006] When an exception to be processed is captured, the corresponding exception process is suspended; a target storage path is created based on the exception to be processed, and the suspended exception process is unsuspended; target exception logs associated with the exception to be processed are continuously collected based on the target storage path until the exception process terminates.

[0007] Optionally, a target storage path can be created based on the exception to be processed, including:

[0008] Determine at least one preset exception level corresponding to the exception to be processed; if the remaining space in the preset exception storage space is greater than a preset threshold, and at least one preset exception level includes a preset target level, then obtain the exception number corresponding to the exception to be processed; in the exception storage space, create a target storage path according to the exception number and the target level.

[0009] Optionally, each anomaly level includes at least one type of anomaly; determining at least one preset anomaly level corresponding to the anomaly to be processed includes:

[0010] Determine the exception type of the exception to be processed; determine whether each exception level includes the exception type of the exception to be processed; determine the exception level that includes the exception type of the exception to be processed as the exception level corresponding to the event to be processed.

[0011] Optionally, a preset number of exception numbers are provided, each exception number being unique; a target storage path is created based on the exception number and target level, including:

[0012] Retrieve the exception sequence number corresponding to each historical exception from the exception storage space; the exception storage space stores historical exception logs associated with each historical exception, and each historical exception log carries an exception sequence number; match the exception sequence number corresponding to each historical exception with the exception sequence number corresponding to the exception to be processed; if there is a duplicate exception sequence number, delete the historical exception log corresponding to that exception sequence number.

[0013] Optionally, the system includes a first type of log recording the system's operation process, a second type of log created by a preset service, and a third type of log recording the operation process of abnormal processes; target exception logs associated with the exception to be processed are continuously collected based on the target storage path, including:

[0014] Copy the first and third type of logs from the kernel to the target storage path;

[0015] Based on the type of exception level included in the target level, the default service is invoked to copy the second type of logs to the target storage path.

[0016] Optionally, after the abnormal process terminates, the method further includes:

[0017] Package all files in the target storage path to obtain a target compressed file corresponding to the exception to be processed; display the exception to be processed on the terminal based on the target compressed file; wherein, the display method includes at least one of the following: pop-up display, full-screen display based on a colored background.

[0018] Optionally, if an exception to be handled is caught, the method further includes:

[0019] Obtain an idle target thread from a pre-defined thread pool and create a session on that target thread; the thread pool includes at least one thread; execute log collection transactions corresponding to pending exceptions based on the session.

[0020] Specifically, after an abnormal process terminates, the target thread is released to the thread pool.

[0021] Optionally, the method further includes:

[0022] If the terminal is in a restart state based on historical exceptions of the third type of exception, determine whether there are log files associated with historical exceptions of the third type of exception stored in the preset path; the third type of exception is an exception based on the kernel framework; if so, create a target storage path based on the historical exception, and collect target exception logs associated with the historical exception based on the target storage path.

[0023] On the other hand, embodiments of this application provide an anomaly log collection device, the device comprising:

[0024] The management module is used to suspend the corresponding exception process if an exception to be handled is captured.

[0025] The creation module is used to create a target storage path based on the exception to be processed, and to call the management module to cancel the suspension of the exception process.

[0026] The collection module is used to continuously collect target exception logs associated with the exception to be processed based on the target storage path until the exception process terminates.

[0027] In another aspect, embodiments of this application provide an electronic device, which includes:

[0028] The present application includes a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of an exception log collection method provided in the embodiments of the present application.

[0029] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of an exception log collection method provided in this application.

[0030] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of an exception log collection method provided in this application.

[0031] The beneficial effects of the technical solutions provided in this application are:

[0032] This application provides a method for collecting exception logs. After an exception is captured, it is identified as a pending exception. The corresponding exception process is paused, and a target storage path is created based on the pending exception during the pause. After the exception process resumes execution, target exception logs associated with the pending exception are continuously collected until the exception process terminates. The exception log collection method provided in this application improves the effectiveness and efficiency of the collected logs, and thereby assists developers in quickly locating exceptions and identifying problems in the code. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0034] Figure 1 A software architecture diagram provided for an embodiment of this application;

[0035] Figure 2 A flowchart illustrating an exception log collection method provided in an embodiment of this application;

[0036] Figure 3a A schematic diagram of the structure of an anomaly log collection device provided in an embodiment of this application;

[0037] Figure 3b A schematic diagram of another abnormal log collection device provided in an embodiment of this application;

[0038] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0039] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0040] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0042] Building upon the background technology, and addressing the aforementioned problems of existing exception handling methods, this application provides an exception log collection method applicable to any electronic device. Optionally, the electronic device uses the Android operating system (which can be simply referred to as the system). Therefore, exceptions generated in the system can be captured using the native exception handling module of the Android operating system. After capturing an exception, log collection is performed using the mobile method for collecting exception logs provided in this application. This log collection process involves collecting exception logs provided by the native exception handling module. The log collection process may include: if a pending exception is captured, suspending the corresponding exception process; creating a target storage path based on the pending exception and canceling the suspension of the exception process; and continuously collecting target exception logs associated with the pending exception based on the target storage path until the exception terminates.

[0043] Optionally, this native exception handling module may include the `crash_dump` service and the `tombstone` service from the `debuggerd` service. The `crash_dump` service is used to detect Native Exceptions (Exceptions associated with C / C++ frameworks, abbreviated as NE; C / C++ frameworks refer to function libraries written in the C / C++ programming language), while the `tombstone` service can provide `tombstone_**`. This native exception handling module may also include the `AMS` (ActivetyManagerService) service and the `DMS` (DropBoxManagerService) service. The `AMS` service is used to capture Java Exceptions (Exceptions associated with Java frameworks / Java applications, abbreviated as JE), while the `DMS` service is used to provide Dropbox files.

[0044] In this context, situations where functions within a C / C++ framework are called occur within the system. Exceptions that occur during the execution of this framework are collectively referred to as Native Exceptions. When a Native Exception (NE) is generated, the system invokes the tombstone service to create a tombstone_** file (where ** represents the process identifier corresponding to the recorded information).

[0045] Since most of the applications or services running on the system are based on the Java language, and these applications or services rely on frameworks including Java frameworks (function libraries written in the Java programming language), exceptions that occur during the execution of Java applications or Java frameworks are collectively referred to as Java Exceptions. When an NE (Exception in Java) is generated, the system calls the DMS (Distributed Management Service) to create a Dropbox file.

[0046] It should be noted that the dropbox file and the tombstone_** file are exception log files provided by Android's native modules, and their specific contents can be found in relevant technologies.

[0047] In addition, exceptions can also occur at the system's kernel level, leading to process crashes or system restarts. These exceptions are referred to as kernel exceptions (KEs) in related technologies.

[0048] Generally, if the operating system or application does not have exception handling procedures in place after an exception occurs, a crash or prolonged unresponsiveness (ANR) will likely follow, both leading to a poor user experience. For example, Java crashes caused by Java Exclusion (JE) manifest as Java application processes failing to run normally, or Java frameworks loaded into memory failing to be invoked. Native crashes caused by Native Exclusion (NE) manifest as C / C++ frameworks loaded into memory failing to be invoked, indirectly causing related application processes to malfunction. Furthermore, kernel crashes caused by Kernel Exclusion (KE) can cause the system to stop running entirely. Therefore, developers need to collect exception logs for different exceptions, analyze the problems in the program, and thus better adjust the program.

[0049] Optionally, the electronic device can be a consumer electronic device such as a mobile phone, tablet, wearable device, or game console; it can also be a home electronic device such as a television. It should be noted that any device capable of running the Android operating system can be used as this electronic device.

[0050] Optionally, the method provided in this application embodiment can be implemented as a standalone application or a functional module / plugin of an application. For example, the application can be dedicated exception log collection software or other applications with exception log collection functions. Through this application, exception logs associated with exceptions during process execution can be collected.

[0051] To more clearly describe the solutions provided by the embodiments of this application, the technical solutions of the embodiments of this application and the technical effects produced by the technical solutions of this application are explained below through the description of several exemplary implementation methods. It should be noted that the following implementation methods can be referred to, borrowed from or combined with each other, and the same terms, similar features and similar implementation steps in different implementation methods will not be described again.

[0052] Figure 1 The diagram illustrates the software architecture upon which an exception log collection method relies. In the software architecture diagram, the operating system is mainly divided into three layers: the application framework layer (hereinafter referred to as the Java layer), the native framework layer (hereinafter referred to as the Native layer), and the kernel layer (hereinafter referred to as the Kernel layer).

[0053] Optionally, the exception log collection method primarily relies on the EMC (Exception Monitored and Collected) module in the native layer. After starting the EMC module, an EMC process is obtained. During the initialization phase of the EMC process, it is first configured as a socket server, registering and subscribing to messages with the AMS and crash_dump services so that the AMS and crash_dump services can send notifications about exceptions to the EMC process after catching them.

[0054] Next, we will provide a detailed explanation of the structure and interaction of the Java layer, Native layer, and Kernel layer.

[0055] The AMS and DMS services are deployed in the Java layer and configured as socket clients. When the AMS service detects a Dropbox Error (JE), it first obtains the associated abnormal process and suspends it. Next, it sends a signal identified as "socket client_AMS" to the EMC process to notify it of the JE occurrence. The EMC process determines whether to create a target storage path based on the received signal and sends feedback to the AMS service after creation. Upon receiving this feedback, the AMS service unsuspends the abnormal process. After creating the target storage path, the EMC process also sends it to the DMS service to instruct it to save the Dropbox file to that path.

[0056] The Native layer includes the C / C++ framework. This layer is further divided into two layers: the NativeService layer, which is closely connected to the Java layer, and the Native Library layer, which is closely connected to the Kernel layer.

[0057] The Native Service layer includes the Debuggred service and the coredump_pipe service; the Debuggred service includes the crash_dump service and the tombstone service. During the initialization of the coredump_pipe service, crash_dump service, and tombstone service, these services are configured as socket clients. Specifically, after the crash_dump service captures a newline (NE), it first obtains the abnormal process associated with that NE, suspends the abnormal process, and then sends an exception signal carrying the NE to the EMC process. Upon receiving the exception signal, the EMC process determines whether to create a target storage path and, after creating the path, reports back to the crash_dump service. Upon receiving the feedback, the crash_dump service unsuspends the abnormal process. After creating the target storage path, the EMC process also sends the target storage path to the coredump_pipe object to notify it to determine that a core file has been generated and that the core file's storage path is the target storage path. The EMC process also sends the target storage path to the tombstone service to notify it to copy the tombstone_** file to the target storage path. In addition, the Native Service layer also includes the Surfaceflinger service, debug_cmd service, and logd service, all of which assist the EMC process in collecting logs.

[0058] The Native Library layer includes the Libbinder, Libenc, Libeswdrawtext, Liblog, Libgui, and Libui libraries. The Libeswdrawtext library is a function library built upon the Libgui and Libui libraries. The EMC process can call the Libbinder library to configure a socket server, enabling it to interact with services configured as socket clients. The EMC process can also call the Libenc library to collect environmental information about the exception's occurrence; it can use Libeswdrawtext to display the collected exception logs; and it can call the Liblog library to collect specific exception logs related to the exception's occurrence.

[0059] The kernel layer includes system log storage paths. When an exception occurs, the system creates and stores exception logs in the corresponding paths; different types of logs have different storage paths. For example... Figure 1As shown, there are a total of four paths: " / proc / ...", " / sys / ...", " / data / ...", and " / d / binder / ...". When the EMC process redirects exception logs from the system log storage path to the target storage path, it uniformly adjusts the names of the exception logs. Exception logs obtained via shell commands are also uniformly named.

[0060] Optionally, the adjustment process for some files can be referenced in Table 1 below.

[0061] Table 1

[0062]

[0063]

[0064]

[0065] Files numbered 1 through 9 are related to the abnormal process. These files only exist during the execution of the abnormal process and are deleted by default once the abnormal process terminates. Files numbered 10 through 13 record the memory information of the abnormal process. File number 14 is a backup log file in the buffer, which can be redirected to the target storage path via shell commands. Files numbered 15 through 44 are other ordinary log files. File number 45 is a memory snapshot of the abnormal process created by the core_dump service, recording the address information, register information, and stack call information at the time of the abnormal process crash. File number 46 is a tombstone file created by the tombstone service, recording the address at which the abnormal process crashed and the stack call information at the time of the crash. File number 47 is a dropbox file created by the DMS service, which is used to store debugging information or abnormal information that occurred in the system. This abnormal information includes: crash information of a process, or abnormal information that the system has encountered an unexpected error and needs to be restarted.

[0066] Taking file number 1 in Table 1 as an example, the renamed file is named "PROCESS_FD". Here, "[pid]" represents the identifier of a specific process.

[0067] After storing all collected exception logs to the target storage path, the EMC process begins packaging the files in the target storage path to obtain a target compressed file associated with the exception. The EMC process then displays the exception based on this target compressed file.

[0068] After seeing the displayed exception information, developers can locate the exception based on the displayed information or compressed file, thereby identifying the problem in the code and making corresponding adjustments.

[0069] Based on the above software architecture, this application also provides a method for collecting exception logs. For example... Figure 2 As shown, the method includes the following steps S210 to S220.

[0070] S210, if an pending exception is caught, suspend the exception process corresponding to the pending exception.

[0071] Generally, during code execution, if an abnormal running state occurs, an exception will be thrown. During the execution of service processes or application processes in the system, it is inevitable that they will call the corresponding code in the three layers of the aforementioned software architecture. If any service process or application process encounters an error and throws an exception while calling the corresponding code in the three layers, it can be understood as an exception being thrown by any service process or application process. In this embodiment, the exceptions thrown by the process are referred to as pending exceptions. These pending exceptions include JE, NE, and KE. KE is an exception thrown by the system's kernel layer; after this exception occurs, the system may crash or the process may remain unresponsive for a period of time. For JE and NE, one or more processes may crash or remain unresponsive for a period of time.

[0072] Optionally, JE represents the first type of exception, which is the exception thrown by the Java layer code in the above software architecture when it encounters an error during runtime; NE represents the second type of exception, which is the exception thrown by the Native layer code in the above software architecture when it encounters an error during runtime; and KE represents the third type of exception, which is the exception thrown by the Kernel layer code in the above software architecture when it encounters an error during runtime.

[0073] Optionally, if the exception to be handled is a Type I exception, the Type I service is invoked to suspend or unsuspend the exception process. Specifically, after a JE is thrown, the AMS service is invoked to capture the JE; after determining which process threw the JE during runtime, that process is identified as the exception process, i.e., the exception process corresponding to the exception to be handled. After capturing the JE, the AMS service is invoked to suspend the exception process.

[0074] Optionally, if the exception to be handled is a Type II exception, the Type II service is invoked to suspend or unsuspend the exception process. Specifically, after an NE is thrown, the crash_dump service is invoked to capture the NE; after determining which process threw the NE during its runtime, that process is identified as the exception process, i.e., the exception process corresponding to the exception to be handled. After capturing the NE, the crash_dump service is invoked to suspend the exception process.

[0075] S220: Create a target storage path based on the pending exception and cancel the suspended exception process.

[0076] Specifically, if the exception to be handled is JE, the AMS service is invoked to unsuspend the exception process. If the exception to be handled is NE, the crash_dump service is invoked to unsuspend the exception process. After the exception process restarts, log collection can begin.

[0077] S230 continuously collects target exception logs associated with the exception to be processed based on the target storage path until the exception process terminates.

[0078] This application provides a method for collecting exception logs. After an exception is captured, it is identified as a pending exception. The corresponding exception process is paused, and a target storage path is created based on the pending exception during the pause. After the exception process resumes operation, target exception logs associated with the pending exception are continuously collected until the exception process terminates. This method benefits from two advantages. First, log collection occurs after the exception occurs and during the period when the exception process ends. The exception logs generated during this period are highly correlated with the pending exception, resulting in a high proportion of effective exception logs. These logs help developers quickly locate exceptions. Second, by pausing the exception process after the exception occurs, the occurrence context of the exception is protected. Even if a new exception occurs due to a chain reaction, developers can clearly understand the order of occurrence between the pending exception and the new exception through the collected logs and deduce the logic behind the different exceptions based on this order. In other words, this method of protecting the context also helps developers quickly locate exceptions.

[0079] It is also necessary to know how to store exception logs during the collection process, as this allows developers to quickly find exception logs and perform code analysis based on the collected exception logs.

[0080] In an optional embodiment, creating a target storage path based on the exception to be processed may specifically include the following steps S220a1 to S220a3.

[0081] S220a1, determine at least one preset exception level corresponding to the exception to be processed.

[0082] Optionally, there are three preset anomaly levels: Level 1, Level 2, and Level 3. Each anomaly level includes at least one type of anomaly. Level 1 includes JE, NE, and KE, indicating that anomaly logs associated with JE, NE, and KE can be collected. Level 2 includes NE and KE, indicating that anomaly logs related to NE and KE can be collected. Level 3 includes KE, indicating that anomaly logs related to KE can be collected.

[0083] Specifically, determine the exception type of the exception to be processed; determine whether each exception level includes the exception type of the exception to be processed; and determine the exception level that includes the exception type of the exception to be processed as the exception level corresponding to the event to be processed.

[0084] In one example, if the exception to be handled is JE, then the exception level corresponding to JE is the first exception level. If the exception to be handled is NE, then the exception level corresponding to NE is the first exception level and the second exception level.

[0085] S220a2, if the remaining space in the preset abnormal storage space is greater than the preset storage threshold, and at least one preset abnormal level includes the preset target level, then obtain the abnormal number corresponding to the abnormal to be processed.

[0086] The system's storage space includes an exception storage space for storing exception logs collected for any given exception. This exception storage space has a preset storage threshold. Optionally, this preset threshold is a parameter greater than zero and can be set empirically; for example, the data size of a compressed package of a single target exception log can be used as the preset threshold.

[0087] Optionally, the size of the remaining space can be determined based on the stored historical exception logs and a preset storage threshold.

[0088] If the remaining space in the preset abnormal storage space is not greater than a preset threshold, and / or at least one preset abnormal level does not include the target level, the abnormal sequence number will not be obtained and the creation of the target storage path will be abandoned. Without creating a target storage path, there is no need to collect abnormal logs.

[0089] If the remaining space is less than the preset threshold, it indicates that the exception storage space is nearing full and cannot store any more exception logs. The target level is the range of exceptions that need to be collected by the user. If at least one exception level does not include the target level, it means that the exception to be processed is not within the range of exceptions that need to be collected, and processing of the exception can be abandoned.

[0090] S220a3: In the abnormal storage space, create a target storage path based on the abnormal sequence number and target level.

[0091] Optionally, the exception logs can be concatenated based on the exception sequence number, the target level identifier, and the time when the exception was captured. A folder can then be created in the exception storage space based on the concatenated result. The storage path of this folder can be used as the target storage path to unify all target exception logs.

[0092] For example, the folder name could be: Exception Number_Target Level Identifier_Capture Time_Other Information.

[0093] Optionally, a preset number of exception numbers are set. After the target storage path is created each time a pending exception is captured, an exception number is assigned to the pending exception according to the order of the exception numbers.

[0094] The exception storage space contains historical exception logs corresponding to multiple historical exceptions. Optionally, these historical exception logs can be stored as compressed files or folders. The exception sequence number corresponding to each historical exception is obtained based on the file information of each historical exception log. The exception sequence number corresponding to each historical exception is matched with the exception sequence number corresponding to the exception to be processed; if a duplicate exception sequence number exists, the historical exception log corresponding to that exception sequence number is deleted.

[0095] Among them, the first historical exception log captured after system startup has high analytical value (e.g., it may be the cause of other exceptions) and needs to be retained. This type of exception log is distinguished from other historical exception logs by carrying a preset flag.

[0096] Since the exception storage space is limited, it can no longer store new exception logs after a certain amount of exception logs have been stored. However, by setting exception sequence numbers, new exception logs are given the opportunity to be stored, while old exception logs are deleted in turn. This allows for real-time updates of the content stored in the exception storage space, ensuring that the latest exception logs are always stored there.

[0097] The above embodiments explored how to protect the occurrence context of an exception after it has been captured, and pre-created a target storage path. The purpose of these embodiments is to create an environment for collecting exception logs. Next, a detailed explanation will be provided on how to collect exception logs for pending exceptions.

[0098] In an optional embodiment, logs can be collected based on a target level.

[0099] Optionally, based on the input configuration instructions, one of the three exception levels mentioned above can be selected as the target level. This target level is the exception log that can be collected after the exception to be handled occurs. Before debugging the code, developers determine which exception level to set as the target level so that they can quickly locate the problem in the code being debugged by using the collected exception logs.

[0100] Optionally, the system includes three types of logs: a first type of log recording the system's operation process, a second type of log created by a preset service, and a third type of log recording the operation process of abnormal processes. Target exception logs associated with the pending exception are continuously collected based on the target storage path, specifically including:

[0101] Copy the first and third type of logs from the kernel to the target storage path;

[0102] For example, referring to Table 1 above again, the files shown in Table 1 from number 1 to number 9 are files related to abnormal processes, that is, the third type of logs; the files shown in numbers 10 to number 44 are files generated during system operation, that is, the first type of logs.

[0103] It can also call a preset service to copy the second type of logs to the target storage path based on the type of exception level included in the target level.

[0104] Referring again to Table 1 above, if the preset target level includes JE, the dropbox file created by the DMS service is copied to the target storage path; the original storage address of the dropbox file can be found in file number 47 in Table 1. If the preset target level includes NE, the tombstone file created by the tombstone service is copied to the target storage path, and the coredump_pipe object is called to create a core_file file in the target storage path; the original storage address of the tombstone file can be found in file number 46 in Table 1.

[0105] Since a KE (Knowledge Exclusion) event may cause the system to crash and shut down before the abnormal process crashes, an alternative method for collecting exception logs is required in this situation.

[0106] In an optional embodiment, the method further includes:

[0107] If the terminal is in a restart state based on historical exceptions of the third type of exception, determine whether there are log files associated with historical exceptions of the third type of exception stored in the preset path; the third type of exception is an exception based on the kernel framework.

[0108] Optionally, if so, a target storage path is created based on historical anomalies, and target anomaly logs associated with historical anomalies are collected based on the target storage path. The method for creating the target storage path can be found in steps S220a1 to S220a3.

[0109] Optional, if not, no target storage path will be created to store exception logs related to this pending exception.

[0110] In an optional embodiment, after the abnormal process terminates, the method further includes the following steps Sb1 to Sb2.

[0111] Sb1 packages all files in the target storage path to obtain the target compressed file corresponding to the exception to be processed.

[0112] Optionally, the created folder can be compressed to obtain a compressed file corresponding to the exception to be processed, which is the target compressed file. The name of this compressed file is the same as the name of the created folder.

[0113] Sb2 displays pending exceptions on the terminal based on the target compressed file; the display method includes any of the following: pop-up display, full-screen display based on a colored background.

[0114] Optionally, obtain the exception information to be displayed based on the acquired target compressed file. Combine this exception information in an ordered manner to obtain a string. Display this string via a pop-up window or against a colored background.

[0115] In one example, the exception information obtained is as follows:

[0116] Exception type information: can be JE, KE, or NE.

[0117] Exception event information: only obtained when JE is captured, and can be crash or ANR;

[0118] Thread information: may include the thread name;

[0119] Process information: may include the process name;

[0120] Storage information: i.e., the target storage path mentioned above.

[0121] The exception information may also include other information. The example shown is only one example. Relevant technical personnel can customize the content of the exception information according to their needs.

[0122] Optionally, when selecting a colored background for display, a colored area can be selected on the terminal screen. This colored area can be freely enlarged, moved, maximized, or minimized. One or more exception messages can be displayed on the colored area, and each exception message is displayed sequentially according to its generation time. A clearing operation can also be performed on this colored area to remove the exception messages. The background color of this colored area can be any conspicuous color, such as red or blue.

[0123] In an optional embodiment, if an exception to be processed is captured, but the target storage path has not been created after conditional judgment, then it is not necessary to generate a target compressed file. In this case, exception information can be obtained from a portion of the exception logs and displayed.

[0124] In one example, when the storage space is less than 800M (i.e., the preset threshold, which can be adjusted according to actual needs, and this application does not limit it), in addition to obtaining the above-mentioned abnormal information, an item is added to the abnormal information: the remaining space of the disk is not greater than 800M, and the target abnormal log is not saved.

[0125] Typically, multiple processes run on a system. Therefore, at the same time, or while processing one pending exception, new pending exceptions may arise. The question then becomes how to handle each pending exception.

[0126] In an alternative embodiment, multiple exception log collection transactions for pending exceptions can be processed in parallel by setting up a thread pool.

[0127] Optionally, after catching the pending exception, it may also include:

[0128] Obtain an idle target thread from a pre-defined thread pool and create a session on that target thread; the thread pool includes at least one thread; execute log collection transactions corresponding to pending exceptions based on the session.

[0129] This session records all information about the pending exception, such as the identifier of the exception process, the capture time of the pending exception, and the target storage path.

[0130] Optionally, the target thread can be released to the thread pool after the abnormal process terminates.

[0131] The process of collecting logs based on session execution and pending exceptions includes steps S210 to S230. Figure 3a A schematic diagram of an anomaly log collection device is shown. As shown in Figure 3, the device 300 includes the following modules.

[0132] The management module 310 is used to suspend the corresponding exception process if an exception to be handled is captured.

[0133] The creation module 320 is used to create a target storage path based on the exception to be processed, and to call the management module 310 to cancel the suspended exception process.

[0134] The collection module 330 is used to continuously collect target exception logs associated with the exception to be processed based on the target storage path until the exception process terminates.

[0135] Optionally, the creation module 320, in creating the target storage path based on the exception to be processed, is specifically used for:

[0136] Determine at least one preset exception level corresponding to the exception to be processed; if the remaining space in the preset exception storage space is greater than a preset threshold, and at least one preset exception level includes a preset target level, then obtain the exception number corresponding to the exception to be processed; in the exception storage space, create a target storage path according to the exception number and the target level.

[0137] Optionally, each anomaly level includes at least one type of anomaly; the creation module 320, in determining at least one preset anomaly level corresponding to the anomaly to be processed, is specifically used for:

[0138] Determine the exception type of the exception to be processed; determine whether each exception level includes the exception type of the exception to be processed; determine the exception level that includes the exception type of the exception to be processed as the exception level corresponding to the event to be processed.

[0139] Optionally, the creation module 320 has a preset number of exception numbers, each of which is different; it creates a target storage path based on the exception number and target level, specifically for:

[0140] Retrieve the exception sequence number corresponding to each historical exception from the exception storage space; the exception storage space stores historical exception logs associated with each historical exception, and each historical exception log carries an exception sequence number; match the exception sequence number corresponding to each historical exception with the exception sequence number corresponding to the exception to be processed; if there is a duplicate exception sequence number, delete the historical exception log corresponding to that exception sequence number.

[0141] Optionally, the system includes a first type of log recording the system's operation process, a second type of log created by a preset service, and a third type of log recording the operation process of abnormal processes; the collection module 330 continuously collects target exception logs associated with the exception to be processed based on the target storage path, specifically for:

[0142] Copy the first and third types of logs from the kernel to the target storage path; based on the type of exception level included in the target level, call the preset service to copy the second type of logs to the target storage path.

[0143] Optionally, after the abnormal process terminates, the collection module 330 can also be used for:

[0144] Package all files in the target storage path to obtain a target compressed file corresponding to the exception to be processed; display the exception to be processed on the terminal based on the target compressed file; wherein, the display method includes at least one of the following: pop-up display, full-screen display based on a colored background.

[0145] Optional, such as Figure 3b As shown, the device 300 also includes a parallel processing module 340; if an exception to be processed is captured, the parallel processing module 340 is specifically used for:

[0146] Obtain an idle target thread from a pre-defined thread pool and create a session on that target thread; the thread pool includes at least one thread; execute log collection transactions corresponding to pending exceptions based on the session.

[0147] Specifically, after an abnormal process terminates, the target thread is released to the thread pool.

[0148] Optionally, the collection module 330 can also be used for:

[0149] If the terminal is in a restart state based on historical exceptions of the third type of exception, determine whether there are log files associated with historical exceptions of the third type of exception stored in the preset path; the third type of exception is an exception based on the kernel framework; if so, create a target storage path based on the historical exception, and collect target exception logs associated with the historical exception based on the target storage path.

[0150] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0151] This application provides an electronic device including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of an exception log collection method. Compared with related technologies, this method can improve the effectiveness and efficiency of the collected logs, and thereby assist developers in quickly locating exceptions and identifying problems in the code.

[0152] In one alternative embodiment, an electronic device is provided, such as Figure 4 As shown, Figure 4 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0153] Among them, electronic devices include, but are not limited to, the consumer electronic devices or home electronic devices listed in the above embodiments.

[0154] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0155] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0156] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0157] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0158] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A method for collecting exception logs, characterized in that, The method includes: When an pending exception is captured, the exception process corresponding to the pending exception is suspended. Determine at least one preset exception level corresponding to the exception to be processed; if the remaining space in the preset exception storage space is greater than a preset threshold, and the at least one preset exception level includes a preset target level, then obtain the exception number corresponding to the exception to be processed; in the exception storage space, concatenate the exception number, the target level, and the time when the exception to be processed was captured, create a folder in the exception storage space based on the concatenation result, use the storage path of the folder as the target storage path, and cancel the suspension of the exception process; Based on the target storage path, target exception logs associated with the exception to be processed are continuously collected until the exception process terminates.

2. The method according to claim 1, characterized in that, Each anomaly level includes at least one type of anomaly; Determining at least one preset exception level corresponding to the exception to be processed includes: Determine the exception type of the exception to be processed; Determine whether each anomaly level includes the anomaly type of the anomaly to be processed; The anomaly level of the anomaly type that is determined to be an anomaly to be processed is determined as the anomaly level corresponding to the anomaly to be processed.

3. The method according to claim 1, characterized in that, A preset number of exception numbers are provided, each exception number being different; the step of concatenating the exception numbers, the target level, and the time when the exception was captured, and creating a folder in the exception storage space based on the concatenation result, with the storage path of the folder serving as the target storage path, includes: Obtain the exception sequence number corresponding to each of the historical exceptions from the exception storage space; the exception storage space stores historical exception logs associated with each historical exception, and each historical exception log carries an exception sequence number. Match the anomaly number corresponding to each historical anomaly with the anomaly number corresponding to the anomaly to be processed. If the same exception number exists, delete the historical exception log corresponding to that exception number.

4. The method according to claim 1, characterized in that, The operating system includes a first type of log recording the system's operation process, a second type of log created by a preset service, and a third type of log recording the operation process of the abnormal process; the continuous collection of target exception logs associated with the pending exception based on the target storage path includes: Copy the first type of log and the third type of log from the kernel to the target storage path; Based on the type of anomaly level included in the target level, the preset service is invoked to copy the second type of logs to the target storage path.

5. The method according to claim 4, characterized in that, After the abnormal process terminates, the method further includes: Package all files in the target storage path to obtain a target compressed file corresponding to the exception to be processed; The pending exception is displayed on the terminal based on the target compressed file; wherein the display method includes at least one of the following: pop-up display, full-screen display based on a colored background.

6. The method according to claim 1, characterized in that, When an pending exception is captured, the method further includes: Obtain an idle target thread from a preset thread pool and create a session on that target thread; the thread pool includes at least one thread. Based on the session, execute the log collection transaction corresponding to the pending exception; Specifically, after the abnormal process terminates, the target thread is released to the thread pool.

7. The method according to claim 1, characterized in that, The method further includes: If the terminal is in a restart state based on a historical exception of the third type of exception, determine whether there is a log file associated with the historical exception of the third type of exception stored in the preset path; the third type of exception is an exception based on the kernel framework. If so, create a target storage path based on the historical anomaly, and collect target anomaly logs associated with the historical anomaly based on the target storage path.

8. An anomaly log collection device, characterized in that, The device includes: The management module is used to suspend the exception process corresponding to the pending exception when it is captured. A creation module is used to determine at least one preset exception level corresponding to the exception to be processed; if the remaining space in the preset exception storage space is greater than a preset threshold, and the at least one preset exception level includes a preset target level, then the exception number corresponding to the exception to be processed is obtained; in the exception storage space, the exception number, the target level, and the time when the exception to be processed was captured are concatenated, and a folder is created in the exception storage space based on the concatenation result, the storage path of the folder is used as the target storage path, and the management module is called to cancel the suspension of the exception process; The collection module is used to continuously collect target exception logs associated with the exception to be processed based on the target storage path until the exception process terminates.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.