Crash processing method and apparatus, computer program product, and electronic device

Abstract

The present disclosure relates to the technical field of computers, and relates to a crash processing method and device, a computer program product and an electronic device. The method comprises: loading a target crash file to a permanent session through a debugger instance; performing evidence query on the target crash file based on the permanent session to obtain original evidence data, and acquiring corresponding source code context according to the original evidence data; performing cross-validation on the original evidence data and the source code context, and acquiring target evidence data according to the cross-validation result, so as to generate an initial analysis report according to the target evidence data and the source code context; calling multiple review units to concurrently review the initial analysis report to obtain multiple review results, and determining a crash processing result corresponding to the target crash file based on each review result and the initial analysis report; wherein each review unit is configured to review the initial analysis report from different dimensions.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a crash handling method and apparatus, computer program products, and electronic devices. Background Technology

[0002] When numerous backend services run on servers, a crash triggers a kernel dump file (e.g., Coredump), which stores a complete memory image of the process at the moment of the crash. Root cause analysis is crucial for ensuring the stability of online services. This involves loading the dump file and analyzing crash signals, call stacks, register and memory states to determine the cause of the crash. For example, dedicated servers for large-scale multiplayer online games are a typical scenario for this type of crash analysis. However, currently, upon receiving a crash notification, manual analysis and root cause identification are required, which is not only inefficient but also prone to misjudgment, leading to delays in timely crash handling. While large language models can be used, they may fabricate root causes or fixes when evidence is insufficient, resulting in incorrect problem identification.

[0003] It should be noted that the information in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] The purpose of this disclosure is to provide a crash handling method and apparatus, computer program product and electronic device, thereby overcoming, at least to some extent, the defects of the related technologies and improving the efficiency and quality of crash handling.

[0005] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0006] According to one aspect of this disclosure, a crash handling method is provided, comprising: loading a target crash file into a persistent session via a debugger instance; performing an evidence query on the target crash file based on the persistent session to obtain raw evidence data, and obtaining the corresponding source code context based on the raw evidence data; performing cross-validation on the raw evidence data and the source code context, and obtaining target evidence data based on the cross-validation results, so as to generate an initial analysis report based on the target evidence data and the source code context; invoking multiple review units to independently review the initial analysis report, obtaining multiple review results, and determining the crash handling result corresponding to the target crash file based on each review result and the initial analysis report; wherein each review unit is configured to review the initial analysis report from different dimensions.

[0007] According to one aspect of this disclosure, a crash handling apparatus is provided, comprising: a persistence processing module for loading a target crash file into a persistent session via a debugger instance; a data acquisition module for performing evidence query on the target crash file based on the persistent session to obtain original evidence data, and obtaining the corresponding source code context based on the original evidence data; a cross-validation module for performing cross-validation on the original evidence data and the source code context, and obtaining target evidence data based on the cross-validation results, so as to generate an initial analysis report based on the target evidence data and the source code context; and a concurrent review module for calling multiple review units to independently review the initial analysis report, obtaining multiple review results, and determining the crash handling result corresponding to the target crash file based on each review result and the initial analysis report; wherein each review unit is configured to review the initial analysis report from different dimensions.

[0008] According to one aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the above methods.

[0009] According to one aspect of this disclosure, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform any of the above methods by executing the executable instructions.

[0010] The crash handling method in the exemplary embodiments of this disclosure, on the one hand, loads the target crash file into a persistent session through a debugger instance, so that the debugger instance only needs to load the target crash file once, and multiple subsequent evidence query requests can reuse the same persistent session, avoiding the huge time and resource overhead of repeatedly loading the file for each round of query. On the other hand, it obtains the corresponding source code context based on the original evidence data; performs cross-validation on the original evidence data and the source code context, and obtains the target evidence data based on the cross-validation results, integrating source code reading throughout the entire analysis process. Each round of evidence query is guided by the source code logic, and each conclusion is anchored by the source code context, preventing subjective speculation when evidence is lacking, and ensuring that each conclusion is traceable and verifiable. Furthermore, it calls multiple review units to conduct concurrent reviews of the initial analysis report, conducting concurrent reviews of the initial report from multiple independent perspectives, avoiding single-point misjudgments, providing independent quality control for the analysis conclusions, and improving the credibility of the final conclusions. In addition, this disclosure enables crash analysis from loading, automatic querying, automatic cross-validation, automatic report generation, and automatic review without human intervention throughout the entire process, making it suitable for large-scale online environments where crashes occur continuously, achieving unattended operation.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0012] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation.

[0013] Figure 1 A flowchart of a crash handling method according to an exemplary embodiment of the present disclosure is shown.

[0014] Figure 2 A flowchart illustrating an implementation of a continuous debugging mechanism according to an exemplary embodiment of the present disclosure is shown.

[0015] Figure 3 A flowchart illustrating an implementation method for acquiring target evidence data according to an exemplary embodiment of this disclosure is shown.

[0016] Figure 4 A flowchart illustrating an implementation of generating an initial analysis report according to an exemplary embodiment of this disclosure is shown.

[0017] Figure 5 A schematic diagram of the composition of a crash handling apparatus according to an exemplary embodiment of the present disclosure is shown.

[0018] Figure 6 A block diagram of an electronic device according to an exemplary embodiment of the present disclosure is shown.

[0019] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0020] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar structures, and therefore their detailed description will be omitted.

[0021] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details described, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known structures, methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0022] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, or in one or more software-hardened modules, or in different network and / or processor devices and / or microcontroller devices.

[0023] In related technologies, the analysis and processing of operating system-generated dump files mainly relies on manual work by engineers. For example, after receiving a crash notification, engineers manually parse the server, game, and file path information in the notification, log in to the corresponding server, switch to the directory where the core files are located, manually start the command-line debugger to load the dump file, manually type in the command-line debugging commands one by one, repeatedly switch between logs, call stacks, registers, memory, and source code, infer the root cause based on personal experience, and finally manually write an analysis report and send it to relevant personnel. This method has the following drawbacks: the preliminary actions are cumbersome, namely notification parsing, remote login, directory switching, and starting the command-line debugger, which is a long chain of preliminary actions and consumes a lot of preparation time; the context switching is frequent, that is, the analysis process needs to switch repeatedly between multiple information sources such as logs, stacks, registers, memory, and source code, which is inefficient and prone to errors; the session is not reusable, that is, the command-line debugger is used in a one-time manner, and repeated analysis requires reloading, which consumes a lot of time; it depends on personal habits, call chains and data flows are easy to overlook, complex problems are easy to draw conclusions based on experience first and then go back to supplement evidence, and even subjective assumptions may occur, making it difficult to detect misjudgments and difficult to scale up monitoring. In practice, if a large language model is used, there is a problem that the model may fabricate root causes or solutions due to insufficient evidence, and the results obtained are difficult to trace.

[0024] Based on one or more of the above-mentioned problems, an exemplary embodiment of this disclosure provides a crash handling method. Through the coordinated cooperation between persistent sessions, cross-validation, and concurrent review, persistent sessions provide efficient underlying support for multi-round iterative queries of cross-validation, cross-validation provides evidence anchoring for the initial analysis report, and concurrent review provides independent external verification for the analysis conclusions. Together, they realize the transformation from experience-driven to evidence-driven mode and solve the above-mentioned technical problems.

[0025] It should be noted that the exemplary method of this disclosure can be applied to scenarios of server process crash handling, such as the analysis and processing of crash files of dedicated servers for massively multiplayer online games or other server programs, and no specific limitations are imposed on it.

[0026] The crash handling method provided in the exemplary embodiments of this disclosure can be applied to a server, or a cloud server or other network server. The corresponding crash handling apparatus is installed in the server. Correspondingly, in this method executed by the server, the server can respond to a triggering instruction to begin executing the steps in the technical solution of the exemplary embodiments of this disclosure. This triggering instruction can be sent by a user's terminal or triggered locally by the server in response to some automated event. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms. The server can execute background tasks.

[0027] refer to Figure 1 The diagram shown is a flowchart of a crash handling method according to an exemplary embodiment of this disclosure. Figure 1 As shown, the method includes steps S110 to S140: Step S110: Load the target crash file into the resident session via the debugger instance.

[0028] Step S120: Perform evidence query on the target crash file based on the resident session to obtain the original evidence data, and obtain the corresponding source code context based on the original evidence data.

[0029] Step S130: Perform cross-validation on the original evidence data and source code context, and obtain the target evidence data based on the cross-validation results, so as to generate an initial analysis report based on the target evidence data and source code context.

[0030] Step S140: Call multiple review units to concurrently review the initial analysis report, obtain multiple review results, and determine the crash handling result corresponding to the target crash file based on each review result and the initial analysis report; wherein, each review unit is configured to review the initial analysis report from different dimensions.

[0031] The crash handling method in the exemplary embodiments of this disclosure, on the one hand, loads the target crash file into the persistent session through a debugger instance, so that the debugger instance only needs to load the target crash file once, and multiple subsequent evidence query requests can reuse the same persistent session, avoiding the huge time and resource overhead of repeatedly loading the file for each round of query. On the other hand, it obtains the corresponding source code context based on the original evidence data; performs cross-validation on the original evidence data and the source code context, and obtains the target evidence data based on the cross-validation results, integrating source code reading throughout the entire analysis process. Each round of evidence query is guided by the source code logic, and each conclusion is anchored by the source code context, preventing subjective speculation when evidence is lacking, and ensuring that each conclusion is traceable and verifiable. Furthermore, it invokes multiple review units to independently review the initial analysis report, conducting independent reviews of the initial report from multiple independent perspectives, avoiding single-point misjudgments, providing independent quality control for the analysis conclusions, and improving the credibility of the final conclusions. In addition, this disclosure enables crash analysis from loading, automatic querying, automatic cross-validation, automatic report generation, and automatic review without human intervention throughout the entire process, making it suitable for large-scale online environments where crashes occur continuously, achieving unattended operation.

[0032] Steps S110 to S140 will be explained in detail below.

[0033] In step S110, the target crash file is loaded into the resident session via the debugger instance.

[0034] In the exemplary embodiments disclosed herein, a debugger instance is a program entity used to perform crash file analysis, such as the GDB (GNU Debugger) command debugger. It can observe the internal structure and memory usage of a program during execution and can also be used to trace errors in the program. For example, a debugger instance can load crash files (such as core files) and provide various debugging functions such as stack backtracking, thread information viewing, register viewing, memory viewing, and structure field printing. The target crash file is a snapshot of the current process memory captured and saved by the operating system when a computer program (such as a game server process) experiences an abnormal termination (crash) during execution. This file records key information such as the program counter state, function call stack, register values, stack memory, and global variable values ​​at the moment of the crash, serving as the fundamental data source for post-crash analysis.

[0035] The debugger instance loads the target crash file by reading it into memory and parsing it. The debugger instance can verify the crash file format, parse the memory image, restore the symbol table, and establish the mapping between addresses and function names. For crash files of large server programs (such as the Core file generated by the DS game process), their size can reach several gigabytes, the loading process is time-consuming, and consumes a large amount of I / O and memory resources. Therefore, this disclosure loads the file only once and resides in a persistent screen session (daemon). This persistent session is used to process data query requests. It is a persistent interactive session that the debugger instance continuously runs on the remote server after startup and does not terminate with the completion of a single query. It is a background operating system process (such as running in a screen session), continuously waiting for and responding to external command input. This session is independent of the client process that initiated the query; even if the client disconnects, the debugger instance remains running and can be reused for subsequent query requests. The fundamental difference between persistent sessions and ordinary temporary debugging sessions lies in the following: Ordinary sessions terminate the debugger process after each query, requiring a restart and reloading of the crash file for the next query; persistent sessions, on the other hand, keep the debugger process resident in memory, ensuring the availability of loaded crash files and eliminating the overhead of cumbersome pre-processing and repeated loading of large cores. Therefore, data query requests are interactive instructions sent to the debugger instance during analysis to obtain specific information from the crash file, and the query is achieved by reusing the content loaded in the persistent session.

[0036] In one exemplary embodiment, an implementation method for a continuous debugging mechanism is provided. For example... Figure 2 Loading a target crash file into a persistent session via a debugger instance can include: Step S210: Start a persistent session on the remote server as a resident session, and run a debugger instance in the resident session to load the target crash file.

[0037] The remote server is a physical or virtual machine that actually runs the service program containing the target crash file, connected via a network to the client initiating the analysis request (such as the analysis server where the AI ​​Agent resides). The debugger instance also runs on this remote server. Deploying the debugger on the remote server instead of downloading the core file locally avoids the significant bandwidth consumption and time overhead of transferring files across the network. For example, this disclosure allows running GDB as a persistent session on the remote server. A persistent session is a long-lasting interactive session environment that does not terminate with the end of a single interaction cycle. In this disclosure, the persistent session is specifically implemented by starting a background terminal session (such as a screen session in a Linux system) on the remote server, independent of the client process that initiated the start command. Even if the client disconnects or restarts, the session and the debugger instance running within it remain running, continuously waiting for new command input.

[0038] Step S220: Record the status information of the persistent session. The status information is used to locate, access or track the running status of the persistent session to support multi-round reuse queries of the debugger instance.

[0039] State information is structured data used to describe and track the running state of persistent sessions. For example, fields of this state information are recorded in the state file daemon_state.json, including but not limited to the remote server address, the identifier of the persistent session, the log file path of the debugger instance, the log read offset, and the session start time. Based on the state information, the running state of persistent sessions can be located, accessed, or tracked to support multi-round reuse queries on debugger instances.

[0040] Step S230: Determine the query encapsulation interface corresponding to the debugger instance. The query encapsulation interface is used to respond to data query requests and send the data query requests to the debugger instance so that the debugger instance can execute the data query.

[0041] The query encapsulation interface is a unified program call interface that encapsulates the complex logic of underlying interactions with persistent sessions (such as connection management, command sending, output reading, and log offset updates) into atomic operations transparent to the upper layer. The upper-layer AIAgent does not need to concern itself with the specific implementation of the debugger instance to obtain structured query results. This interface enables the complete chain of actions: sending commands, waiting for execution, incrementally reading new output from the end of the log by `log_offset` (i.e., the log read offset), and returning the newly added output and the updated offset. For example, this query encapsulation interface can be specifically implemented as the `gdb_query` function.

[0042] Optionally, query operations based on the query encapsulation interface are executed serially, which means that concurrent operations on the same GDB debugging session are prohibited, resulting in log offset errors.

[0043] Optionally, a safety net can be set up so that when a GDB debugging session survives for more than 2 hours, an alarm flag is returned by querying the encapsulation interface. In this case, the main agent can immediately enter the cleanup phase to close the session and release the debugger instance, thus preventing resources from being occupied for a long time.

[0044] This disclosure employs a one-time initialization action of starting a persistent session and loading a file. Subsequent queries only interact with the existing session through the query encapsulation interface, without needing to consider whether the debugger instance is running or whether the file has already been loaded. This decoupling of session and query allows the loading results of the same crash file to be reused an unlimited number of times, eliminating the overhead of repeated loading.

[0045] In one exemplary embodiment, an implementation method for incrementally reading data is also provided. This implementation method includes: Based on the log read offset of the persistent session included in the status information, incremental data is read through the debugger instance; the safe runtime limit of the persistent session is determined, and the runtime of the persistent session is monitored. When the runtime exceeds the safe runtime limit, the persistent session is closed and the debugger instance is released.

[0046] The log read offset (log_offset) represents the position of bytes already read in the debugger instance's log file. This offset is recorded numerically in the status file, indicating the last position of the end of the log file. When a new query begins, new content in the log file is read from this offset position, without having to reread the entire file from the beginning. In practice, all input commands and execution outputs of the debugger instance are continuously written to the log file. After each query is completed, the debugger instance generates new output content, which is appended to the end of the log file. The offset record indicates the last position read from the log file; by maintaining this value, the system can accurately distinguish between read and unread content. Compared to reading the entire log file from the beginning each time, incremental reading only returns content that was not read previously. The volume of data returned each time is proportional to the output volume generated by the current query, rather than proportional to the total number of queries, greatly reducing data transfer volume.

[0047] The safe runtime limit is a threshold set for the maximum allowed lifespan of a persistent session. When the cumulative runtime of a persistent session since its startup exceeds this threshold, the system will trigger an automatic cleanup process. This threshold is a configurable time parameter, and the specific value can be set according to the actual scenario; for example, it is set to 2 hours in this disclosure. This disclosure takes into account that although persistent sessions can significantly improve query efficiency, they are essentially long-term background processes that occupy the computing resources of remote servers. Without a duration limit, once an anomaly occurs, the session will occupy resources indefinitely, and may even accumulate to the point of affecting the normal operation of the server. Therefore, a safe runtime limit is set to avoid this problem.

[0048] In step S120, an evidence query is performed on the target crash file based on the resident session to obtain the original evidence data, and the corresponding source code context is obtained from the source code management system based on the original evidence data.

[0049] In the exemplary embodiments disclosed herein, a debugger instance in a resident session can issue specific debugging commands to the loaded target crash file to obtain program state information at the time of the crash, i.e., obtain raw evidence data. Each query command extracts information from a specific aspect of the crash file, equivalent to a targeted inquiry into the crash scene. For example, x / 4gx (memory content viewing) can be sent through a wrapper interface. The raw evidence data is the initial program state information directly obtained from the crash file through evidence queries, without processing by upper-level logic. This data is the direct output of the debugger instance to the query commands, such as each line of function call records in the stack backtrace, the hexadecimal display of register values, and the original values ​​of each field in the structure. The source code management system is a system used for storing, versioning, and tracking the history of changes to program source code. The source code management system records every change to the code and assigns a unique version identifier to each version. Based on the source code management system, a source code snapshot accurate to the version corresponding to the target crash file (e.g., obtained by parsing the engine version in the game log) can be provided, ensuring that the source code referenced during the analysis is completely consistent with the code running at the time of the crash. Source code context refers to the source code segment and its surrounding code environment corresponding to a program location in the original evidence data (such as the crash point function, each function in the call stack and its parameters). Specifically, when the original evidence data contains a function name, file name, and line number, the source code context includes the line of code itself, the several lines of code before and after the function, the definition and initialization locations of related variables in the function, the function's call relationships, and the object's lifecycle management code, etc.

[0050] In one exemplary embodiment, an implementation method for obtaining original evidence data and source code context is provided. This involves performing an evidence query on the target crash file based on a persistent session to obtain original evidence data, and then obtaining the corresponding source code context based on the original evidence data, including: First, obtain the stack trace information and / or log data of the target crash file through a debugger instance to obtain the raw evidence data; then, locate the corresponding source code context based on the function call information in the raw evidence data.

[0051] The stack backtrace information is extracted from the target crash file using the debugger instance's `bt` (backtrace) command, recording the function call chain at the moment of the program crash. This data lists the complete function call path from the program entry point (such as the `main` function) to the crash point (i.e., the function containing the last instruction that triggered the crash) in call order. Log data consists of the contents of the runtime log file output by the program instance corresponding to the target crash file during runtime. It can be generated by logging statements in the program, recording the program's execution process, state changes, warning messages, and error messages. Unlike the stack backtrace information, log data is not read from the crash file itself, but obtained from a separate log file generated by the same program instance within the same time window as the crash file. This disclosure can determine the original evidence data based on the obtained stack backtrace information and / or log data. Function call information is key data extracted from the stack backtrace information, used to identify the function identity and location within the stack frame. Specifically, function call information may include at least the function name, the source file path, and the line number in each frame of the stack backtrace. Then, using the source file path and line number in the function call information as an index, the specific source file of the corresponding version can be found in the source code management system, and the file pointer can be positioned at the line number code to obtain the source code context.

[0052] This disclosure allows for the direct reading of factual information from crash files based on function call information in the original evidence data. This ensures that the source code context upon which the analysis is based corresponds functionally to the code executed at the time of the crash, thereby ensuring the accuracy of the source code context.

[0053] In step S130, cross-validation is performed on the original evidence data and source code context, and target evidence data is obtained based on the cross-validation results, so as to generate an initial analysis report based on the target evidence data and source code context.

[0054] In the exemplary embodiments of this disclosure, cross-validation involves bidirectionally comparing and verifying raw evidence data from a debugger instance with the source code context from a source code management system. Specifically, each piece of program state information (such as function calls, variable values, memory contents, etc.) in the raw evidence data should have a corresponding logical interpretation determined within the source code context. For example, whether the logic corresponding to the evidence in the code holds true under the current evidence. Similarly, each logical judgment in the source code context (such as conditional branches, pointer accesses, boundary checks, etc.) should have a corresponding runtime state found in the evidence data. For example, the actual state of the logic in the code at the moment of crash.

[0055] In one exemplary embodiment, a method for acquiring target evidence data is provided. For example... Figure 3 Performing cross-validation on the original evidence data and source code context, and obtaining the target evidence data based on the cross-validation results, may include: Step S310: Determine the preliminary judgment result based on the original evidence data.

[0056] Step S320: Based on the preliminary judgment results, locate the code logic corresponding to the original evidence data from the source code context, and determine the items to be verified based on the code logic.

[0057] Step S330: Generate a first evidence query instruction based on the matter to be verified, and execute the first evidence query instruction through a debugger instance to obtain the first supplementary evidence data of the preliminary judgment result.

[0058] If the first supplementary evidence data meets the sufficient evidence condition, then proceed to step S340 to determine the first supplementary evidence data as the target evidence data. The sufficient evidence condition indicates that an evidence loop has been established for the target crash file, and that the evidence loop is verified through source code context.

[0059] Otherwise, update the first supplementary evidence data to the original evidence data and return to the step of determining the preliminary judgment result, that is, return to step S310.

[0060] Specifically, the preliminary judgment refers to the initial hypothesis about the possible causes of the collapse, established based on the original evidence data. This preliminary judgment is a preliminary result obtained before being systematically verified by the source code context. Furthermore, based on the currently obtained original evidence data and source code context, the reasoning steps that have not yet been fully confirmed and require further evidence to verify or refute are identified, i.e., the matters to be verified are determined. The transformation from original evidence data to target evidence data involves three key actions: first, screening, i.e., excluding marginal evidence that is irrelevant to the root cause of the collapse or only has reference value; second, supplementation, i.e., obtaining key information missing from the original data but essential for identifying the root cause through iterative queries; and third, confirmation, i.e., verifying the consistency between various pieces of evidence and their logical self-consistency with the root cause judgment through the source code context. The fundamental difference between target evidence data and original evidence data is that target evidence data is verified knowledge, and its various contents have formed a logical closed loop, collectively constituting a complete supporting chain for the root cause of the collapse.

[0061] The evidence sufficiency condition is used to indicate that an evidence loop has been established for the target crash file, and the evidence loop is verified through the source code context. When the first supplementary evidence data does not meet the evidence sufficiency condition, it can be updated to the original evidence data, that is, steps S310 to S340 are re-executed until the first supplementary evidence data meets the evidence sufficiency condition, and the first supplementary evidence data is determined as the target evidence data.

[0062] Specifically, the sufficiency of evidence condition is a standard used to determine whether the currently obtained evidence data is sufficient to support the analytical conclusion. It includes three progressive levels: completeness of the evidence loop, meaning that each reasoning step from the occurrence of the collapse to the identification of the root cause is supported by corresponding evidence data; exclusion of alternative hypotheses, meaning that all other reasonable hypotheses that could explain the same collapse phenomenon have been excluded through evidence, ensuring the uniqueness of the root cause determination; and source code verifiability, meaning that each piece of key evidence can be logically verified by finding its corresponding code location in the source code context, for example, down to the file path and line number. When all three conditions are met simultaneously, the evidence is considered sufficient, the evidence query cycle can be terminated, and the report generation stage can begin. Based on this, conclusions can be avoided when evidence is insufficient or invalid queries can continue when evidence is sufficient, ensuring the accuracy of the processing results while avoiding the waste of ineffective resources and improving processing efficiency.

[0063] In one exemplary embodiment, an implementation of investigation depth circuit breaking is also provided. That is, the process of repeatedly executing the following steps until target evidence data is obtained further includes: First, monitor the number of evidence queries and the cumulative amount of query output data obtained for the same investigation target; the investigation target includes the target stack frame or target memory address in the crash stack.

[0064] Secondly, when the number of evidence queries reaches a preset query threshold, and / or the amount of query output data reaches a preset data volume threshold, the evidence query for the investigated object is interrupted, and an intermediate report containing confirmed information and unconfirmed doubts is generated based on the currently obtained evidence data.

[0065] Finally, the context corresponding to the intermediate report is compressed, while the confirmed information and the doubts to be confirmed are retained, so as to re-plan the evidence query for the target crash file based on the compressed context.

[0066] Specifically, the investigation target is the analysis objective of the current evidence query, including but not limited to the target stack frame in the crash stack and the target memory address. During the cross-validation loop, multiple consecutive probes may be performed on the same investigation target, such as repeatedly querying the value of the same pointer in different contexts or examining different ranges of memory pointed to by that pointer. The number of evidence queries is the number of evidence query instructions executed on the same investigation target. Each time a new query instruction is executed on the investigation target through a resident session, the corresponding counter is incremented by 1 to determine this number. The query output data volume is the cumulative size of the output data returned by all evidence queries on the same investigation target. After each query execution, new output generated by the debugger instance is added to the cumulative output data volume of that investigation target.

[0067] Based on this, a circuit breaker mechanism is implemented to prevent unlimited queries. The preset query count threshold is the maximum number of evidence queries allowed for the same investigation target. When the query count reaches this threshold, a deep circuit breaker is triggered, interrupting the current investigation direction. This threshold can be configured according to the analysis scenario, for example, set to 5 times. That is, if sufficient evidence to make a judgment is not obtained after 5 consecutive queries on the same stack frame or the same pointer, the exploration in that direction is interrupted. The preset data volume threshold is the maximum cumulative amount of query output data allowed for the same investigation target, for example, 500 rows, which can be flexibly set according to the actual scenario. When the cumulative amount of output data obtained from an investigation target reaches this threshold, a deep circuit breaker is triggered, interrupting the current investigation direction.

[0068] Furthermore, after a deep investigation is triggered, an analysis document can be generated based on the currently obtained evidence data, containing confirmed information and points of suspicion yet to be confirmed. This allows for an objective record of the investigation's results up to the time of the circuit breaker. Context compression simplifies the collected evidence data and source code context, reducing the amount of information required for subsequent analysis. For example, confirmed information can be retained, points of suspicion yet to be confirmed can be retained, and redundant information can be discarded. Further, the evidence search for the target crash file can be re-planned based on the compressed context; the search process is similar to the above and will not be repeated.

[0069] This disclosure defines the boundaries of the investigation by setting thresholds for the number of investigations and the amount of data, ensuring that the analysis process is executed within a controllable range of resources and preventing the analysis time from getting out of control and the token consumption from exploding due to unlimited investigation.

[0070] In one exemplary embodiment, an implementation method for memory integrity checking is also provided. This implementation method includes: first, obtaining a target memory object from original evidence data and performing a memory layout integrity check on the target memory object to obtain an integrity check result; second, if the integrity check result indicates that the memory layout of the target memory object is abnormal, determining the target write source of the memory layout abnormality based on at least one of object allocation logic, object release logic, and asynchronous task information in the source code context; and finally, determining a preliminary judgment result based on the target write source.

[0071] The target memory object is a data structure instance directly related to the crash point. For example, in the crash point code, the object instance pointed to by the pointer is the target memory object. This disclosure obtains the memory content of the target memory object at the time of the crash through evidence query instructions, compares it one by one with the object memory layout defined in the source code context to determine whether the memory content of the object is complete and whether it meets expectations. Then, after performing a memory layout integrity check on the target memory object, a judgment is made, namely, whether the memory layout is normal or abnormal. In actual implementation, the root cause of memory layout abnormality may be illegal writing to the target object's memory caused by certain behaviors in the program, including but not limited to out-of-bounds writing, re-access to released objects, data races in a concurrent environment, delayed callbacks, or timer operations modifying the object state at inappropriate times.

[0072] Specifically, when an anomaly is determined, the target write source of the memory layout anomaly can be determined based on at least one of the object allocation logic, object release logic, and asynchronous task information in the source code context, and then a preliminary judgment result can be determined based on the target write source.

[0073] This disclosure improves the accuracy of analysis by checking the integrity of the memory layout and, while confirming that the object's state is abnormal, tracing the source of the write that caused the exception through the allocation logic, release logic, and asynchronous task information in the source code context.

[0074] In one exemplary embodiment, an implementation for generating an initial analysis report is also provided. For example... Figure 4 Generating an initial analysis report based on target evidence data and source code context may include: Step S410: Based on the correspondence between the target evidence data and the source code context, determine the root cause of the target crash file and the corresponding repair plan; wherein, the target evidence data includes at least one evidence entry to support the root cause of the crash.

[0075] Step S420: Establish a reference relationship between at least one evidence entry and the corresponding code location in the source code context.

[0076] Step S430: Generate an initial analysis report containing the root cause of the crash, the solution, and the reference relationships.

[0077] As mentioned above, the target evidence data is a set of key evidence that has been cross-validated and cyclically screened and confirmed, sufficient to support the determination of the root cause of the crash. An evidence item is the smallest independent unit in the target evidence data, such as the value of the pointer variable at the crash point being 0x00000000. The root cause of the crash is the fundamental reason for the abnormal termination of the program, i.e., the underlying defect that triggers the crash. In this disclosure, the determination of the root cause of the crash must simultaneously meet two conditions: evidence support, i.e., each reasoning step on which the root cause depends has corresponding target evidence data as a factual basis; and source code verification, i.e., the root cause can be logically self-consistently explained in the source code context. This disclosure can determine a repair plan based on logical analysis in the source code context and the determined root cause of the crash, which may include specific code modification locations and code-level modification instances. For example, this disclosure can generate corresponding repair plans by unit based on the logical analysis results in the source code context and the determined root cause of the crash.

[0078] This involves establishing a reference relationship between at least one evidence item and its corresponding code location in the source code context. This creates a ternary mapping structure that binds each conclusion in the report (including root cause analysis, reasoning steps, and remedial solutions) to the evidence item in the target evidence data on which it is based, and the corresponding code location of that evidence item in the source code context. Through this reference relationship, the reliability of any conclusion can be independently verified along the chain of conclusion, evidence item, and source code line number, without relying on trust in the authority of the report author, thus making the report conclusions traceable.

[0079] Optionally, when establishing the correspondence, the corresponding source file can be located from the source code context based on the function call information corresponding to the root cause of the crash, and the flow data can be traced upstream from the crash point in the source code file; then, the evidence entries can be correlated with at least one code position in the traced flow data.

[0080] The function call information corresponding to the root cause of the crash is function identification data directly related to the root cause, extracted from the stack frame path finally confirmed by cross-validation. Specifically, after the root cause of the crash is determined through cross-validation, the root cause is associated with a specific function in the call stack, which may be the crash point function itself or a function upstream in the call chain. This function call information includes at least the function name, the source file path where the function is located, and the line number of the code in the function that is directly related to the root cause. Based on this, the source file path in the function call information can be used as an index to find and open the corresponding source file in the source code management system, thus obtaining the source file. For example, when the source file path in the function call information is an absolute path, it can be located directly by that path; when the path is a relative path, the search starts from the root directory of the source code repository and follows the relative path. The crash point is the source code location that actually triggers the crash exception during program execution. Data flow can be traced upstream from the crash point in the source code file, following the reverse time sequence of program execution (i.e., from the crash point to the program entry point), tracing the data source or control flow source layer by layer upwards in the call chain. For example, program execution flows downstream (forward) from the main function to the crash point; while tracing upstream traces back (reverse) from the crash point to the origin of data or control flow.

[0081] Specifically, starting from the crash point, the code is traced upstream layer by layer along the call chain to locate at least one code location (accurate to file path and line number) directly related to the flow of abnormal data in the source code, thus obtaining at least one code location in the stream data. This code location can be a point of assignment / modification of abnormal data, a point of transmission of abnormal data, a point of consumption of abnormal data, or a source of introduction of abnormal data, such as the location where the data is first accessed at or near the crash point itself. Furthermore, a continuous call or assignment chain should be formed in the source code from the crash point to the code location, with each step accurately located by the source code line number, its data state change or execution path corresponding to at least one piece of evidence data, and all located code locations originating from the source code version consistent with the crash time. Then, the traced code locations are bound to the corresponding evidence entries to obtain the aforementioned correspondence.

[0082] This disclosure improves the accuracy of root cause identification by tracing data upstream from the crash point to pinpoint the source of the data anomaly. Based on this, an initial analysis report containing the root cause of the crash, a remediation plan, and related citations can be generated. In other words, the initial analysis report includes conclusions, each conclusion is linked to specific evidence entries and source code locations through citations, and the report is organized according to a preset template, including the root cause, remediation plan, and chain of evidence.

[0083] This disclosure ensures that the cause of the crash analysis matches the target evidence data and source code context by generating an initial analysis report that includes the root cause of the crash, the solution, and the reference relationship. This avoids inaccurate conclusions caused by unreasonable speculation. At the same time, the binding relationship also allows for a complete chain of evidence, which is beneficial for information traceability.

[0084] In one exemplary embodiment, an implementation method for verifying an initial analysis report is also provided, the implementation method including: The initial analysis report is verified according to a preset checklist. If all verification items pass, the initial analysis report is allowed to be output. The preset checklist is used to characterize whether the root causes of the crashes in the initial analysis report meet preset reliability standards. If any verification items fail, evidence queries are performed to update the initial analysis report based on the failed verification items until all verification items pass, at which point the initial analysis report is output.

[0085] The pre-configured checklist is a knowledge file that is pre-configured and automatically maintained and updated by the AI ​​unit during operation. Verification items are the smallest verification units in the checklist. For example, based on historical analysis experience, pre-configured checklists include not paraphrasing GDB evidence, not speculating, and continuing to investigate if evidence is insufficient. These serve as quality control nodes before each analysis begins and before the report is generated. Correspondingly, the pre-configured reliability standard is the quality benchmark that the initial analysis report must meet before formal output, defined by all verification items in the checklist. The core dimensions of the reliability standard include sufficient evidence, verifiable source code, exclusion of alternative hypotheses, and implementable remediation solutions. For example, each conclusion cites the original GDB text, and each frame of the crash stack has source code line numbers. This disclosure allows for flexible configuration of the pre-configured checklist according to actual needs.

[0086] Specifically, if all verification items pass, an initial analysis report is output, which serves as the input for the next stage. Conversely, if any verification items fail, evidence queries are performed to update the initial analysis report based on these failed items. The initial analysis report is then checked using a preset checklist until all verification items pass, at which point the initial analysis report is output. Furthermore, based on the information gaps indicated by the failed verification items, new evidence query commands can be executed through a debugger instance in the resident session to obtain new evidence data needed to fill these gaps. The method for finding new evidence data is consistent with the method for obtaining original evidence data described above and will not be elaborated upon here.

[0087] This disclosure generates targeted supplementary evidence query instructions based on the failed verification items, updates the report and re-verifies only after supplementing the missing information, which not only reduces the correction cost, but also ensures the accuracy of the initial analysis report.

[0088] In step S140, multiple review units are invoked to concurrently review the initial analysis report, resulting in multiple review results. Based on each review result and the initial analysis report, the crash handling result corresponding to the target crash file is determined. Each review unit is configured to review the initial analysis report from different dimensions.

[0089] In an exemplary embodiment of this disclosure, the review unit is an AI subunit configured to perform independent quality checks on the analysis report. Multiple review units are invoked to conduct concurrent blind reviews of the initial analysis report. Each review unit reviews the initial analysis report from different dimensions, obtaining multiple review results, including at least the following dimensions: 1) whether each conclusion in the initial analysis report is supported by the target evidence data; 2) whether there are alternative root causes in the initial analysis report explaining the same crash phenomenon; 3) whether the crash path, object lifecycle, and race condition in the initial analysis report have passed independent verification. Independent verification indicates that the explanation path for reconstructing the crash root cause based on the original evidence data and source code context does not rely on the existing conclusions in the initial analysis report; 4) whether the repair scheme proposed in the initial analysis report meets preset repair conditions.

[0090] This can be understood as the review unit in this disclosure consisting of independent sub-units, each focusing on different dimensions. Furthermore, multiple review units are initiated simultaneously in a single call, conducting independent reviews of the same initial analysis report in parallel. This ensures that all review units begin their reviews within the same time window, working independently without waiting for or interfering with each other. For example, the review unit could be comprised of different large models to increase the diversity of perspectives.

[0091] For example, this disclosure may include four review units. The first review unit may review whether each conclusion in the inspection report is directly supported by the original GDB output, and whether there is any missing evidence or over-inference. The second review unit may construct competing root causes that can explain the same crash phenomenon, verify whether the report's conclusions are overturned by alternative hypotheses, and prevent the omission of other possibilities when identifying a single root cause. For example, at least two alternative hypotheses of equal credibility to the original conclusion may be constructed. The third review unit may independently verify whether the source code file paths, line numbers, object lifecycles, race conditions, and timers referenced in the report are correct, preventing incorrect code references. The fourth review unit may check whether the repair recommendations are specific (e.g., including file:line and before / after), whether they adequately cover the root cause, whether the hierarchy is correct, and whether there is a risk of introducing new problems. For example, for the second review unit, if the initial report concludes that pointer A is a null pointer causing a dereference crash, the alternative hypothesis constructed by the second review unit may be that the pointer is not null, but points to an object that has been released by another thread but is still resident in memory, or that the crash occurred during the engine shutdown phase, and the object destruction was a legitimate shutdown sequence rather than a business bug. Then, by constructing such competing root causes and identifying the necessary GDB commands to falsify them, the principal unit can be considered. If the principal unit cannot falsify the alternative hypothesis, then the alternative hypothesis becomes an unexcluded term, requiring further GDB analysis, i.e., continued acquisition of supplementary evidence data.

[0092] Based on this, and based on the review results and initial analysis report, the crash handling results corresponding to the target crash file are determined to include: First, the results of each review are summarized, and the items to be confirmed are determined based on the summary results.

[0093] Secondly, the number of items to be confirmed is counted. If the count is zero, the initial analysis report is determined as the crash handling result. If the count is non-zero, a second evidence query instruction is determined based on the items to be confirmed. The second evidence query instruction is executed through a debugger instance to obtain second supplementary evidence data. The initial analysis report is updated based on the second supplementary evidence data, and the steps of calling multiple review units for concurrent review are re-executed until the number of items to be confirmed is zero.

[0094] Specifically, the structured review results from multiple review units can be collected and merged. Specific defects in the initial analysis report that are not yet supported by sufficient evidence, have not been ruled out as alternative interpretations, or have not passed independent verification can be designated as items to be confirmed. These items are extracted from the review results of each review unit. For example, if there is a "NEW_EVIDENCE_NEEDED" item, it indicates that supplementary evidence is needed, meaning a certain conclusion lacks GDB evidence support; if there is a "CODE_PATH_UNVERIFIED" item, it indicates that the code path is not verified: source code path / line number / race condition / timer has not been independently verified, etc. The items to be confirmed are counted to obtain a statistical quantity. In the convergence determination, a value of zero indicates convergence, while a non-zero value indicates that further iteration is needed. In the specific implementation, an upper limit should be set on the count. When the quantity exceeds a preset threshold (e.g., more than 20 items in a single round), it indicates that the initial report has systemic quality problems rather than local defects. In this case, even with multiple rounds of supplementary verification, convergence within the allowed number of rounds is unlikely. It should be directly determined as MAX_ROUNDS and a circuit breaker mechanism should be triggered to avoid wasting computational resources on ineffective iterations. The second evidence query instruction is generated based on the specific content of the item to be confirmed, including a set of GDB query commands used to supplement and obtain missing evidence. Then, by executing the second evidence query instruction, new evidence data, i.e., second supplementary evidence data, is obtained from the debugger instance in the resident session. The initial analysis report is updated based on the second supplementary evidence data, and multiple review units are invoked again for concurrent review. The specific review content is consistent with the above description and will not be repeated here. This process is repeated until the number of items to be confirmed is zero, at which point the current initial analysis report can be determined as the crash handling result.

[0095] When convergence is not achieved, this disclosure generates a second evidence query instruction based on the specific content of the item to be confirmed, and repeatedly reviews and verifies by supplementing new evidence, thereby improving the completeness and accuracy of the final crash handling result.

[0096] Based on the foregoing exemplary embodiments, an implementation method for updating a preset checklist is also provided, the implementation method including: After performing concurrent reviews, error patterns are determined based on the review results, recorded in the error rule base, and the corresponding trigger counts are updated. Error patterns represent the types of defects present in the initial analysis report during the analysis process. Specifically, if the trigger count of any error pattern in the error rule base reaches a preset promotion threshold, the corresponding verification item is added to a preset checklist; if any verification item in the preset checklist is not triggered during a preset number of consecutive executions, the verification item is removed from the preset checklist.

[0097] Error patterns are systemic defect types identified during the initial analysis report, including missing evidence, missing or incorrect source code references, failure to eliminate surrogate root causes, unfeasible remediation solutions, and incorrect lifecycle assessments. An error rule base is a knowledge file used to persistently store identified error patterns and their trigger counts, which may include error pattern names, trigger counts, and trigger records. The trigger count refers to the total number of times an error pattern is identified and recorded in each end-to-end crash analysis. After each complete crash analysis process (from evidence collection to final report output), the system compares the initial report and the final report, identifies the error patterns present, and increments the corresponding count in the error rule base. When the trigger count reaches a preset escalation threshold, the corresponding error pattern is escalated to a trigger condition for a checklist item. For example, in this disclosure, the preset escalation threshold is set to 2. If an error pattern is identified in at least two independent crash analyses, it is considered to be widespread rather than a single, accidental occurrence and should be converted into a mandatory checklist item, i.e., recorded as a prerequisite check.

[0098] Correspondingly, if any verification item in the preset checklist is not triggered during a preset number of consecutive executions, the verification item will be removed from the preset checklist. For example, if a verification item has no tendency to violate the rules in the most recent three consecutive analyses (i.e., it has been internalized as a basic capability), it can be removed from the preset checklist to prevent the gate from expanding indefinitely.

[0099] This disclosure, by recording error patterns and their trigger counts, ensures that quality requirements are moved forward while controlling the context bloat of long dialogues.

[0100] In one exemplary embodiment, after completing the analysis of the crash files, this disclosure delivers the analysis results to a designated notification channel according to a preset template, thereby forming a fully automated, unattended closed loop from the occurrence of a crash to the delivery of the conclusion. Optionally, a scheduled task can automatically trigger the scanning of newly added crash files and execute the above-described crash handling process one by one, delivering the conclusion to an instant messaging group according to a fixed template, while simultaneously providing a complete report rendered on a web page. This allows for continuous operation without human intervention and is suitable for large-scale online environments where crashes continue to occur.

[0101] For example, for two clusters (Cluster A / Cluster B), newly added cores can be found by incrementing the modification time (m time) of the memory image file (core file) relative to the baseline. After merging, the current batch is retrieved in ascending order of time. Then, for each core, the analysis process is called sequentially in a synchronous blocking manner, loading the analysis capabilities disclosed above to execute the complete processing steps (steps S110 to S140), producing a comprehensive engineering report final_report.md (crash handling result). Only one core is run at a time to avoid context pollution and conflicts with concurrent command-line debuggers; for cores that do not produce a complete report, intermediate artifacts (such as review_round) are used. The process involves: 1) Initializing the GDB command-line debugger output; 2) Rolling back to construct a report, requiring verbatim citation of the original text and prohibiting AI rewriting to prevent fabrication; 3) Delivering conclusions according to a fixed template. For example, if no new crashes occur, template A can be sent; if new crashes occur, header template B is sent first, followed by a report for each core (for success, template C is sent: server, time, crash type, known signature, root cause, fix, report link; for failure, template D is sent: failure reason and core path). The delivery channel can be an internal group, with web report rendering provided by an internal HTTP service. After successful delivery, the baseline is written back (deliver first, then write back, to prevent missed reports). During write-back, the `ceil` value (integer seconds + 1) is used for `mtime` to avoid duplicate matching in the next round due to decimal seconds. This process achieves a fully automated, unattended closed loop from crash occurrence to conclusion delivery.

[0102] Optionally, a corresponding target crash file is generated each time a crash occurs, and the crash handling process described above can then be performed on that crash to obtain a report corresponding to the target crash file. Accordingly, if multiple crashes occur, multiple reports can be output based on the target crash file, meaning that each crash has a corresponding report result as the crash handling outcome.

[0103] The crash handling method in the exemplary embodiments of this disclosure, on the one hand, loads the target crash file into a persistent session through a debugger instance. The persistent session is used to process data query requests, so that the debugger instance only needs to load the target crash file once, and multiple subsequent evidence query requests can reuse the same persistent session, avoiding the huge time and resource overhead of repeatedly loading the file for each round of query. On the other hand, it obtains the corresponding source code context from the source code management system based on the original evidence data; performs cross-validation on the original evidence data and the source code context, and obtains the target evidence data based on the cross-validation results. Source code reading is integrated throughout the entire analysis process, and each round of evidence query is guided by the source code logic. Each conclusion is anchored by the source code context, preventing subjective speculation when evidence is lacking and ensuring that each conclusion is traceable and verifiable. Furthermore, it calls multiple review units to conduct concurrent reviews of the initial analysis report. By conducting concurrent reviews of the initial report from multiple independent perspectives, it avoids single-point misjudgment, provides independent quality control for the analysis conclusions, and improves the credibility of the final conclusions. Furthermore, this disclosure enables crash analysis from loading, automatic querying, automatic cross-validation, automatic report generation, and automatic review, all without human intervention. It is suitable for large-scale online environments where crashes occur continuously, achieving unattended operation.

[0104] In an exemplary embodiment of this disclosure, a crash handling apparatus is also provided. (See reference...) Figure 5 As shown, the device 500 may include a persistence processing module 510, a data acquisition module 520, a cross-validation module 530, and a concurrency review module 540. Specifically: The persistence processing module 510 is used to load the target crash file into the persistent session through the debugger instance; the data acquisition module 520 is used to perform evidence query on the target crash file based on the persistent session to obtain the original evidence data, and obtain the corresponding source code context based on the original evidence data; the cross-validation module 530 is used to perform cross-validation on the original evidence data and the source code context, and obtain the target evidence data based on the cross-validation results, so as to generate an initial analysis report based on the target evidence data and the source code context; the concurrent review module 540 is used to call multiple review units to independently review the initial analysis report, obtain multiple review results, and determine the crash handling result corresponding to the target crash file based on each review result and the initial analysis report; wherein, each review unit is configured to review the initial analysis report from different dimensions.

[0105] In one exemplary embodiment of this disclosure, loading a target crash file into a persistent session via a debugger instance includes: starting a persistent session on a remote server as a persistent session; running a debugger instance in the persistent session to load the target crash file; recording the state information of the persistent session, which is used to locate, access, or track the running state of the persistent session to support multi-round reuse queries on the debugger instance; determining the query encapsulation interface corresponding to the debugger instance, which is used to respond to data query requests; and sending the data query request to the debugger instance so that the debugger instance executes the data query.

[0106] In one exemplary embodiment of this disclosure, the data acquisition module 520 is further configured to perform: reading incremental data through the debugger instance based on the log read offset of the resident session included in the status information; determining the safe runtime limit of the resident session and monitoring the runtime of the resident session; and closing the resident session and releasing the debugger instance when the runtime exceeds the safe runtime limit.

[0107] In one exemplary embodiment of this disclosure, evidence query is performed on the target crash file based on a resident session to obtain raw evidence data, and the corresponding source code context is obtained from the source code management system based on the raw evidence data. This includes: obtaining the stack backtrace information and / or log data of the target crash file through a debugger instance to obtain raw evidence data; and locating the corresponding source code context from the source code management system based on the function call information in the raw evidence data.

[0108] In one exemplary embodiment of this disclosure, cross-validation is performed on the original evidence data and the source code context, and target evidence data is obtained based on the cross-validation result. This includes: repeatedly executing the following process until the target evidence data is obtained: determining a preliminary judgment result based on the original evidence data; locating the code logic corresponding to the original evidence data from the source code context based on the preliminary judgment result, and determining the item to be verified based on the code logic; generating a first evidence query instruction based on the item to be verified, and executing the first evidence query instruction through a debugger instance to obtain first supplementary evidence data of the preliminary judgment result; if the first supplementary evidence data meets the evidence sufficiency condition, then the first supplementary evidence data is determined as the target evidence data; otherwise, the first supplementary evidence data is updated to the original evidence data, and the process returns to the step of determining the preliminary judgment result; wherein, the evidence sufficiency condition is used to indicate that an evidence loop of the target crash file has been established, and the evidence loop is verified through the source code context.

[0109] In one exemplary embodiment of this disclosure, the following process is repeated until target evidence data is obtained, further comprising: monitoring the number of evidence queries against the same investigation object and the cumulative amount of query output data obtained; wherein the investigation object includes a target stack frame or target memory address in the crash stack; when the number of evidence queries reaches a preset query count threshold and / or the amount of query output data reaches a preset data volume threshold, the evidence query against the investigation object is interrupted, and an intermediate report containing confirmed information and unconfirmed doubts is generated based on the currently obtained evidence data; the context corresponding to the intermediate report is compressed, and the confirmed information and unconfirmed doubts are retained, so as to re-plan the evidence query against the target crash file based on the compressed context.

[0110] In one exemplary embodiment of this disclosure, determining a preliminary judgment result based on original evidence data includes: obtaining a target memory object from the original evidence data and performing a memory layout integrity check on the target memory object to obtain an integrity check result; if the integrity check result indicates that the memory layout of the target memory object is abnormal, determining the target write source of the memory layout abnormality based on at least one of the object allocation logic, object release logic, and asynchronous task information in the source code context; and determining the preliminary judgment result based on the target write source.

[0111] In one exemplary embodiment of this disclosure, generating an initial analysis report based on target evidence data and source code context includes: determining the root cause of the crash of the target crash file and the corresponding repair scheme based on the correspondence between the target evidence data and the source code context; wherein the target evidence data includes at least one evidence entry to support the root cause of the crash; establishing a reference relationship between the at least one evidence entry and the corresponding code location in the source code context; and generating an initial analysis report containing the root cause of the crash, the repair scheme, and the reference relationship.

[0112] In one exemplary embodiment of this disclosure, after generating an initial analysis report based on target evidence data and source code context, the method further includes: verifying the initial analysis report according to a preset checklist; if all verification items pass, the initial analysis report is allowed to be output; the preset checklist is used to characterize whether the root cause of the crash in the initial analysis report meets a preset reliability standard; if there are any verification items that fail, evidence queries are performed to update the initial analysis report based on the failed verification items, until the initial analysis report is output after all verification items pass.

[0113] In one exemplary embodiment of this disclosure, establishing a reference relationship between at least one evidence entry and the corresponding code location in the source code context includes: locating the corresponding source code file from the source code context based on the function call information corresponding to the root cause of the crash, and tracing the stream data upstream from the crash point in the source code file; and establishing a correspondence between the evidence entry and at least one code location in the traced stream data.

[0114] In one exemplary embodiment of this disclosure, the device further includes an information update module configured to perform: after performing concurrent reviews, determining an error mode based on each review result, recording the error mode in an error rule base, and updating the corresponding trigger count; the error mode is used to represent the type of defect present in the initial analysis report during the analysis process; if the trigger count of any error mode in the error rule base reaches a preset promotion threshold, then adding the verification item corresponding to the error mode to a preset checklist; if any verification item in the preset checklist is not triggered during a preset number of consecutive executions, then removing the verification item from the preset checklist.

[0115] In one exemplary embodiment of this disclosure, multiple review units are invoked to concurrently review the initial analysis report, resulting in multiple review results. This includes: invoking multiple review units to conduct concurrent blind reviews of the initial analysis report; wherein each review unit reviews the initial analysis report from different dimensions, resulting in multiple review results, including at least the following dimensions: whether each conclusion in the initial analysis report is proven by the target evidence data; whether there is an alternative root cause in the initial analysis report to explain the same crash phenomenon; whether the crash path, object lifecycle, and race condition in the initial analysis report are independently verified, wherein independent verification is used to indicate the explanatory path for reconstructing the root cause of the crash based on the original evidence data and source code context, without relying on the existing conclusions in the initial analysis report; and whether the repair scheme proposed in the initial analysis report meets the preset repair conditions.

[0116] In one exemplary embodiment of this disclosure, determining the crash handling result based on each review result and the initial analysis report includes: summarizing each review result and determining the items to be confirmed based on the summary result; counting the number of items to be confirmed, and if the count is zero, determining the initial analysis report as the crash handling result; if the count is non-zero, determining a second evidence query instruction based on the items to be confirmed, executing the second evidence query instruction through a debugger instance to obtain second supplementary evidence data, updating the initial analysis report based on the second supplementary evidence data, and re-executing the step of calling multiple review units for concurrent review until the number of items to be confirmed is zero.

[0117] Since the details of each functional module of the crash handling apparatus of the exemplary embodiments of this disclosure have been described in the exemplary embodiments of the crash handling method described above, they will not be repeated here.

[0118] It should be noted that although several modules or units of the crash handling apparatus have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0119] Exemplary embodiments of this disclosure also provide a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the crash handling method described above.

[0120] In one implementation, the computer program product can be a tangible product containing a computer program, such as a computer-readable storage medium storing the computer program. The readable storage medium can be a storage medium based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, including but not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. For example, the computer program product can be implemented as a non-volatile storage medium storing a computer program, such as read-only memory, NAND flash memory, etc.

[0121] In one implementation, the computer program product can be an intangible product containing a computer program. For example, the computer program product can be implemented as a virtual digital product, such as an executable file, installation package, or other digital file storing the computer program.

[0122] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, and C++. Program code can execute entirely on the user's computing device, partially on the user's computing device, or as a standalone software package. It can also execute partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0123] Computer programs can be carried or transmitted via signals such as electricity, magnetism, light, electromagnetic fields, and infrared radiation. Electronic devices can convert the signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code is used to cause the electronic device to execute (more specifically, the processor of the electronic device to execute) the method steps of various exemplary embodiments of this disclosure, such as the crash handling method described above.

[0124] Furthermore, in an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method is also provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform an exemplary method of any of the above-described methods by executing the executable instructions.

[0125] The following is for reference. Figure 6 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 6 The electronic device 600 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0126] like Figure 6 As shown, the electronic device 600 may include: a processor 610, a memory 620, a bus 630, an I / O (input / output) interface 640, and a network adapter 650.

[0127] Memory 620 may include volatile memory, such as RAM 621 and cache unit 622, and may also include non-volatile memory, such as ROM 623. Memory 620 may also include one or more program modules 624, such program modules 624 including, but not limited to: operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 624 may include the modules in the above-described device.

[0128] The processor 610 may include one or more processing units, such as an AP (Application Processor), a modem processor, a GPU (Graphics Processing Unit), an ISP (Image Signal Processor), a controller, an encoder, a decoder, a DSP (Digital Signal Processor), a baseband processor, and / or an NPU (Neural-Network Processing Unit).

[0129] The processor 610 can be used to execute executable instructions stored in the memory 620 to perform method steps of various embodiments of this disclosure, such as... Figure 1 The steps are shown.

[0130] Bus 630 is used to connect different components of electronic device 600 and may include a data bus, an address bus and a control bus.

[0131] Electronic device 600 can communicate with one or more external devices 700 (such as keyboard, mouse, external controller, etc.) through I / O interface 640.

[0132] Electronic device 600 can communicate with one or more networks via network adapter 650. For example, network adapter 650 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 650 can communicate with other modules of electronic device 600 via bus 630.

[0133] In one embodiment, the electronic device 600 further includes a display for displaying a graphical user interface.

[0134] although Figure 6 As not shown in the diagram, other hardware and / or software modules may also be configured in the electronic device 600, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

[0135] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software aspects, which may be referred to as "circuit," "module," or "system," respectively.

[0136] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. A crash handling method, characterized in that, include: Load the target crash file into the persistent session via a debugger instance; Based on the resident session, an evidence query is performed on the target crash file to obtain the original evidence data, and the corresponding source code context is obtained based on the original evidence data; Cross-validation is performed on the original evidence data and the source code context, and target evidence data is obtained based on the cross-validation results, so as to generate an initial analysis report based on the target evidence data and the source code context; Multiple review units are invoked to independently review the initial analysis report, resulting in multiple review results. Based on each review result and the initial analysis report, a crash handling result corresponding to the target crash file is determined. Each review unit is configured to review the initial analysis report from different dimensions.

2. The method according to claim 1, characterized in that, The step of loading the target crash file into the persistent session via a debugger instance includes: A persistent session is started on a remote server as the persistent session, and the debugger instance is run in the persistent session to load the target crash file; The status information of the persistent session is recorded. The status information is used to locate, access or track the running status of the persistent session in order to support multi-round reuse queries of the debugger instance. The query encapsulation interface corresponding to the debugger instance is determined. The query encapsulation interface is used to respond to data query requests and send the data query requests to the debugger instance so that the debugger instance can perform data queries.

3. The method according to claim 2, characterized in that, The method further includes: Based on the log read offset of the resident session included in the status information, incremental data is read through the debugger instance; The safe runtime limit of the persistent session is determined, and the runtime of the persistent session is monitored. When the runtime exceeds the safe runtime limit, the persistent session is closed and the debugger instance is released.

4. The method according to claim 1, characterized in that, The step of performing an evidence query on the target crash file based on the persistent session to obtain raw evidence data, and obtaining the corresponding source code context based on the raw evidence data, includes: The original evidence data is obtained by acquiring the stack backtrace information and / or log data of the target crash file through the debugger instance. The corresponding source code context is located based on the function call information in the original evidence data.

5. The method according to claim 1, characterized in that, The step of performing cross-validation on the original evidence data and the source code context, and obtaining the target evidence data based on the cross-validation results, includes: Repeat the following procedure until the target evidence data is obtained: Based on the aforementioned original evidence data, a preliminary judgment result is determined; Based on the preliminary judgment results, the code logic corresponding to the original evidence data is located from the source code context, and the matters to be verified are determined based on the code logic; A first evidence query instruction is generated based on the matter to be verified, and the first evidence query instruction is executed through the debugger instance to obtain first supplementary evidence data of the preliminary judgment result; If the first supplementary evidence data meets the sufficient evidence condition, then the first supplementary evidence data is determined as the target evidence data; otherwise, the first supplementary evidence data is updated to the original evidence data, and the process returns to the step of determining the preliminary judgment result. The sufficient evidence condition indicates that an evidence loop for the target crash file has been established, and the evidence loop is verified by the source code context.

6. The method according to claim 5, characterized in that, The process of repeatedly performing the following steps until the target evidence data is obtained also includes: Monitor the number of evidence queries and the cumulative amount of query output data obtained for the same investigation target; wherein, the investigation target includes the target stack frame or target memory address in the crash stack; When the number of evidence queries reaches a preset query number threshold, and / or the amount of query output data reaches a preset data amount threshold, the evidence query for the investigated object is interrupted, and an intermediate report containing confirmed information and unconfirmed doubts is generated based on the currently acquired evidence data. The context corresponding to the intermediate report is compressed, and the confirmed information and the doubts to be confirmed are retained, so as to re-plan the evidence query for the target crash file based on the compressed context.

7. The method according to claim 5, characterized in that, The preliminary judgment result determined based on the original evidence data includes: The target memory object is obtained from the original evidence data, and a memory layout integrity check is performed on the target memory object to obtain the integrity check result. If the integrity check result indicates that the memory layout of the target memory object is abnormal, the target write source of the abnormal memory layout shall be determined based on at least one of the object allocation logic, object release logic and asynchronous task information in the source code context. The preliminary judgment result is determined based on the target input source.

8. The method according to claim 5, characterized in that, The step of generating an initial analysis report based on the target evidence data and the source code context includes: Based on the correspondence between the target evidence data and the source code context, the root cause of the target crash file and the corresponding repair plan are determined; wherein, the target evidence data includes at least one evidence entry to support the root cause of the crash. Establish a reference relationship between the at least one evidence entry and the corresponding code location in the source code context; Generate an initial analysis report containing the root cause of the crash, the repair plan, and the reference relationships.

9. The method according to claim 8, characterized in that, After generating the initial analysis report based on the target evidence data and the source code context, the method further includes: The initial analysis report is verified according to a preset checklist. If all verification items pass, the initial analysis report is allowed to be output. The preset checklist is used to characterize whether the root cause of the crash in the initial analysis report meets the preset reliability standard. If any verification items fail, supplementary evidence queries are performed based on the failed verification items to update the initial analysis report until all verification items pass, at which point the initial analysis report is output.

10. The method according to claim 8, characterized in that, The step of establishing a reference relationship between the at least one evidence entry and the corresponding code location in the source code context includes: Based on the function call information corresponding to the root cause of the crash, locate the corresponding source code file from the source code context, and trace the flow data upstream from the crash point in the source code file; The evidence entries are associated with at least one code location in the traced streaming data.

11. The method according to claim 9, characterized in that, The method further includes: After performing concurrent reviews, error patterns are determined based on the review results, the error patterns are recorded in the error rule base, and the corresponding trigger counts are updated; the error patterns are used to indicate the types of defects present in the initial analysis report during the analysis process; If the trigger count of any error pattern in the error rule base reaches the preset promotion threshold, the verification item corresponding to the error pattern is added to the preset checklist. If any verification item in the preset checklist is not triggered during a preset number of consecutive executions, then the verification item is removed from the preset checklist.

12. The method according to claim 1, characterized in that, The process involves calling multiple review units to independently review the initial analysis report, resulting in multiple review results, including: The multiple review units are invoked to conduct independent blind reviews of the initial analysis report; Each of the aforementioned review units reviews the initial analysis report from different dimensions to obtain the multiple review results, which include at least the following dimensions: Whether each conclusion in the initial analysis report is supported by the target evidence data; Does the initial analysis report include alternative root causes that explain the same collapse phenomenon? Whether the crash path, object lifecycle and race condition in the initial analysis report have been independently verified, the independent verification is used to indicate that the explanation path of reconstructing the root cause of the crash based on the original evidence data and the source code context does not rely on the existing conclusions of the initial analysis report; Does the repair plan proposed in the initial analysis report meet the preset repair conditions? 13. The method according to claim 1, characterized in that, The determination of the crash handling result corresponding to the target crash file based on the review results and the initial analysis report includes: Summarize the review results and determine the items to be confirmed based on the summary results; The number of items to be confirmed is counted. If the count is zero, the initial analysis report is determined as the crash handling result. If the statistical quantity is non-zero, a second evidence query instruction is determined based on the item to be confirmed. The second evidence query instruction is executed through the debugger instance to obtain second supplementary evidence data. The initial analysis report is updated based on the second supplementary evidence data. The step of calling multiple review units for independent review is re-executed until the quantity of the item to be confirmed is zero.

14. A crash handling device, characterized in that, include: The persistence module is used to load the target crash file into the persistent session via the debugger instance; The data acquisition module is used to perform evidence query on the target crash file based on the resident session, obtain the original evidence data, and obtain the corresponding source code context based on the original evidence data; The cross-validation module is used to perform cross-validation on the original evidence data and the source code context, and obtain target evidence data based on the cross-validation results, so as to generate an initial analysis report based on the target evidence data and the source code context; The concurrent review module is used to call multiple review units to independently review the initial analysis report, obtain multiple review results, and determine the crash handling result corresponding to the target crash file based on each review result and the initial analysis report; wherein, each review unit is configured to review the initial analysis report from different dimensions.

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

16. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to perform the method of any one of claims 1 to 13 by executing the executable instructions.

Images