Core dump collapse reason positioning method and device, equipment and storage medium

Abstract

The invention discloses a core dump crash reason positioning method and device, equipment and a storage medium, relates to the technical field of code fault positioning, and discloses a core dump crash reason positioning method, which comprises the following steps of: obtaining a program source code and running log information, and analyzing a core dump file to obtain crash state information; constructing an address-function-code mapping relation through the crash state information and the program source code; positioning a fault code in the program source code according to the address-function-code mapping relation to obtain a program call chain and a fault code block; and positioning a core dump crash reason according to the fault code block, the program call chain and the running log information. Through the technical means of fusing the crash state information, the program source code and the running log information and constructing the address-function-code mapping relation, the technical effect of accurately positioning the core dump crash reason is achieved.

Description

Technical Field

[0001] The present application relates to the technical field of code fault location, and in particular to a method, apparatus, device and storage medium for locating the cause of a core dump crash. Background Art

[0002] In software development and runtime environments, core dump files are crucial for recording the memory state at the time of a program crash. They help developers analyze the cause of the crash. Traditionally, analyzing core dump files relies on the symbol table. The symbol table contains symbolic information such as function and variable names within the program. This table maps memory addresses in the core dump file to meaningful symbols, allowing developers to quickly locate the crashing code point. Due to limited storage space, a program's symbol table is often truncated. Furthermore, the symbol table may be lost, or its version may not match the actual running program. These situations render traditional core dump analysis methods that rely on the symbol table ineffective, making it difficult to locate the cause of the program crash.

[0003] In the absence of a symbol table, developers often attempt to analyze log files generated during program execution to identify exception information or operation logs before and after a crash. However, even if exception information is recorded in the log file, it is typically described in text format and cannot be directly linked to memory addresses or specific code locations in the core dump file. Developers must manually infer possible crash points based on the descriptions in the log file and their understanding of the code. This approach is not only inefficient but also prone to errors. Especially when the program logic is complex and the code size is large, developers find it difficult to accurately locate the specific code location, making it difficult to pinpoint the cause of the program crash, which greatly complicates software development and system maintenance.

[0004] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device, equipment and storage medium for locating the cause of a core dump crash, aiming to solve the technical problem that the cause of a program crash cannot be effectively located in a Coredump file in the absence of a symbol table.

[0006] To achieve the above objectives, the present application proposes a method for locating the cause of a core dump crash, the method comprising:

[0007] Obtain program source code and running log information, and parse core dump files to obtain crash status information;

[0008] Constructing an address-function-code mapping relationship through the crash status information and the program source code;

[0009] Locating the fault code in the program source code according to the address-function-code mapping relationship to obtain a program call chain and a fault code block;

[0010] The cause of the core dump crash is located based on the fault code block, the program call chain, and the running log information.

[0011] In one embodiment, the step of constructing an address-function-code mapping relationship using the crash status information and the program source code includes:

[0012] Extracting the crash memory address, register status, and program counter value according to the crash status information;

[0013] Extracting function entry addresses and key code block features based on the program source code;

[0014] Constructing an address-code mapping according to the crash memory address, the function entry address, and the key code block characteristics;

[0015] Determine the function name and source code line number of the crash address based on the address-code mapping, the register status, and the program counter value;

[0016] An address-function-code mapping relationship is constructed according to the function name, the source code line number, and the address-code mapping.

[0017] In one embodiment, after the step of constructing an address-function-code mapping relationship based on the function name, the source code line number, and the address-code mapping, the method further includes:

[0018] Retrieving the log content corresponding to the function name in the operation log information according to the function name to obtain the function log content;

[0019] Analyze the function call sequence, function execution times, parameter passing information, and key variable status in the function log content to obtain analysis results;

[0020] Based on the analysis result, the address-function-code mapping relationship is modified to improve the address-function-code mapping relationship.

[0021] In one embodiment, the step of locating the fault code in the program source code according to the address-function-code mapping relationship and obtaining the program call chain and the fault code block includes:

[0022] Determining the crash source code location corresponding to the crash memory address based on the address-function-code mapping relationship;

[0023] According to the crash source code location, obtain the corresponding crash function body and calling context;

[0024] Reconstructing a program call chain according to the crashed function body and the calling context;

[0025] A function call address is obtained according to the program call chain, and the function call address and the program source code are mapped to obtain a fault code block.

[0026] In one embodiment, the step of locating the cause of the core dump crash based on the fault code block, the program call chain, and the execution log information includes:

[0027] Obtaining an abnormal call path and an upstream function call relationship based on the fault code block and the program call chain;

[0028] Retrieving fault log content from the operation log information according to the abnormal call path and the upstream function call relationship;

[0029] Analyze the fault log content to obtain fault variable status and function execution behavior;

[0030] The core dump crash cause is located according to the fault variable state, the function execution behavior, the abnormal call path, and the upstream function call relationship.

[0031] In one embodiment, the step of obtaining the abnormal call path and the upstream function call relationship based on the fault code block and the program call chain includes:

[0032] Analyzing abnormal memory operations in the fault code block, wherein the abnormal memory operations include pointer access, memory allocation and release, and array indexing;

[0033] According to the memory exception operation and the program call chain, an exception call path where the memory exception operation is located and an upstream function call relationship are determined.

[0034] In one embodiment, before the steps of obtaining program source code and operation log information and parsing the core dump file to obtain crash status information, the following steps are further included:

[0035] When compiling the program in the test environment, enable the debug information generation instruction to generate the initial executable file;

[0036] Separating the symbol table from the initial executable file to obtain a debugging executable file;

[0037] Performing version identification management on the debugging executable file to obtain a test executable file and a production executable file;

[0038] Memory operations during the running of the test executable file and the production executable file are monitored and recorded.

[0039] In addition, to achieve the above-mentioned purpose, the present application also proposes a core dump crash cause location device, which includes: an acquisition module for acquiring program source code and operation log information, and parsing the core dump file to obtain crash status information;

[0040] A construction module, configured to construct an address-function-code mapping relationship based on the crash status information and the program source code;

[0041] A mapping module, configured to locate the fault code in the program source code according to the address-function-code mapping relationship, and obtain a program call chain and a fault code block;

[0042] A positioning module is used to locate the cause of the core dump crash based on the fault code block, the program call chain and the running log information.

[0043] In addition, to achieve the above-mentioned purpose, the present application also proposes a core dump crash cause locating device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the core dump crash cause locating method as described above.

[0044] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is executed by a processor, the steps of the core dump crash cause locating method as described above are implemented.

[0045] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps of the core dump crash cause locating method as described above.

[0046] One or more technical solutions proposed in this application have at least the following technical effects:

[0047] By obtaining program source code, runtime log information, and parsing core dump files to obtain crash status information, the system further uses the crash status information and program source code to construct an address-function-code mapping relationship, thereby locating the fault code in the program source code, obtaining the program call chain and the fault code block, and combining the fault code block, program call chain, and runtime log information to determine the core dump crash cause. This solves the problem in the existing technology of difficulty in locating the cause of crashes due to missing symbol tables or version mismatches, breaks through the limitations of traditional reliance on symbol tables for core dump file analysis, and achieves the effect of accurately locating the cause of crashes in scenarios without symbol tables, improving the efficiency and accuracy of fault diagnosis and reducing the cost of software development and system maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0049] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0050] Figure 1 A flowchart of the first embodiment of the method for locating the cause of a core dump crash is provided in this application;

[0051] Figure 2 A flowchart of the second embodiment of the method for locating the cause of a core dump crash is provided in this application;

[0052] Figure 3 A schematic diagram of a simplified process of locating the cause of a core dump crash provided in Example 2 of the present application;

[0053] Figure 4 This is a schematic diagram of the module structure of the core dump crash cause location device according to an embodiment of the present application;

[0054] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the core dump crash cause locating method in the embodiment of the present application.

[0055] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0056] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0057] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0058] The main solution of the embodiment of the present application is: obtaining program source code and operation log information, and parsing the core dump file to obtain crash status information; constructing an address-function-code mapping relationship through the crash status information and the program source code; locating the fault code in the program source code according to the address-function-code mapping relationship, and obtaining a program call chain and a fault code block; locating the cause of the core dump crash according to the fault code block, the program call chain and the operation log information.

[0059] In this embodiment, for ease of description, the following description is made with the core dump crash cause identification and location device as the execution subject.

[0060] Since the existing technology cannot effectively locate the cause of the program crash in the Coredump file in the absence of a symbol table, the present application provides a solution to obtain crash status information by obtaining program source code, operation log information, and parsing core dump files, and further using the crash status information and program source code to construct an address-function-code mapping relationship, thereby locating the fault code in the program source code, obtaining the program call chain and the fault code block, and combining the fault code block, the program call chain, and the operation log information to determine the core dump crash cause. This solves the problem in the existing technology that the cause of the crash is difficult to locate due to the lack of a symbol table or version mismatch, breaks through the limitations of traditional reliance on a symbol table for core dump file analysis, and achieves the effect of accurately locating the cause of the crash in a scenario without a symbol table, thereby improving the efficiency and accuracy of fault diagnosis and reducing the cost of software development and system maintenance.

[0061] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of implementing the above functions, a core dump crash cause location device, etc. The following uses a core dump crash cause location device as an example to illustrate this embodiment and the following embodiments.

[0062] Based on this, the embodiment of the present application provides a method for locating the cause of a core dump crash, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the method for locating the cause of a core dump crash in this application.

[0063] In this embodiment, the core dump crash cause location method includes steps S10 to S40:

[0064] Step S10, obtaining program source code and operation log information, and parsing the core dump file to obtain crash status information;

[0065] It's important to note that program source code is the original program code written in programming languages like C and C++. It contains the program's logic, function definitions, variable declarations, and other content, and is the foundation for the program to implement its various functions. Program source code determines the program's behavior at runtime. Developers develop and optimize programs by writing and modifying source code.

[0066] In addition, the run log information is a variety of information recorded during the program's operation, including operation records, exception information, key events, etc. This information can help developers understand the program's execution process and troubleshoot problems that arise during program operation.

[0067] In addition, a core dump file (coredump file) saves information such as the program's memory and register states at the time of a program crash. Coredump files record key data at the moment of the program crash, and by analyzing them, the cause of the crash can be determined. For example, when a C++ program crashes due to a null pointer dereference, the coredump file will save the state of relevant memory data at the time of the crash, as well as information such as the program counter and registers.

[0068] In addition, crash status information is parsed from the core dump file and reflects the state of the program at the time of the crash. This includes memory information, register status, and program counter value. Memory information shows the storage status of data in memory at the time of the program crash; register status records the values of each register at the time of the program crash; and the program counter value indicates the location of the instruction being executed at the time of the program crash.

[0069] It is understandable that the program source code corresponding to the generated Coredump file is obtained from the place where the program source code is stored. This may be the developer's local code repository, or the code backed up in the deployment environment. Collect the operation log information generated during the program operation. These logs may be stored in the local file system, a dedicated log server, etc. Special tools (such as gdb) can be used to parse the core dump file. During the parsing process, the tool will extract data such as memory information, register status, program counter value, etc. in the file. The parsed data is organized into crash status information to provide basic data for subsequent analysis of the cause of the program crash. For example, a C language program crashes at runtime and generates a Coredump file. The developer obtains the corresponding source code from the code repository, collects the operation log from the log file, and then uses the gdb tool to parse the Coredump file to obtain crash status information such as the value of the variable in the memory when the program crashes, the data in the register, and the instruction position pointed to by the program counter.

[0070] Step S20, constructing an address-function-code mapping relationship using the crash status information and the program source code;

[0071] It's important to note that address-function-code mappings map memory addresses in core dump files to functions and specific lines of code in the program's source code. This mapping converts memory addresses into meaningful functions and code, making it easier for developers to pinpoint the specific location of a program crash.

[0072] It's understandable that the memory addresses in the core dump file are matched to these code signatures. GDB is used to load the executable file and the core dump file to obtain the function call stack address at the time of the crash. The objdump tool is used to view the assembly code near the crash address. In GDB, the info proc mappings command is used to determine the memory region (such as the code segment, heap, or stack) to which the crash address belongs. The addr2line tool is used to convert the function call stack address at the time of the crash into the executable file of the test environment that is consistent with the version management.

[0073] Furthermore, it is understood that the mapping relationship between addresses, functions, and code can be further corrected and improved by combining information from runtime logs, such as function call records and variable value changes. For example, the log records the calling sequence and parameter passing of a function, and based on this information, the function and code line corresponding to the memory address can be more accurately determined.

[0074] In a feasible implementation, step S20 may include steps S21 to S25:

[0075] Step S21, extracting the crash memory address, register status and program counter value according to the crash status information;

[0076] It's important to note that the crash memory address refers to the memory location being accessed or operated upon when the program crashes. A program crash occurs when a program encounters an error, such as accessing illegal memory or a memory out-of-bounds error. The memory address involved in this situation is the crash memory address. For example, in an array out-of-bounds access error, the program attempts to access memory outside the array's bounds. This out-of-bounds memory address is the crash memory address.

[0077] Registers are high-speed storage units within the CPU that temporarily store information such as instructions, data, and addresses. Register status refers to the values stored in each register at the time of the program crash. Different registers have different uses. For example, the instruction pointer register (IP) stores the address of the next instruction to be executed, while general-purpose registers can be used to store data and calculation results. By analyzing register status, we can understand the CPU execution context at the time of the program crash.

[0078] In addition, the program counter (PC) is a special register that always points to the address of the next instruction to be executed by the CPU. The program counter value is the address stored in this register when the program crashes. The program counter can indicate which instruction the program was executing at the moment of the crash.

[0079] As can be understood, the crash status information is parsed. Crash status information is typically stored in a specific format in a core dump file. The debugging tool gdb can be used to load the core dump file and retrieve the information within. The crash memory address is then searched and extracted from the parsed information. This may require locating the crash memory address record using specific identifiers or offsets, depending on the structure and format of the information. Register status is extracted. Different CPU architectures have different register sets, and the parsing process requires extracting the value of each register according to the corresponding architecture specifications. The program counter value is also extracted. The program counter value typically has a specific identifier or storage location and can be retrieved using specific search methods. For example, if a Linux-based C program crashes, using gdb to load the core dump file allows specific commands to retrieve the crash memory address, the values of each register, and the program counter value. Extracting this critical information provides foundational data for subsequent analysis. The crash memory address helps locate the specific memory location where the program operated when the error occurred, the register status reflects the CPU execution context, and the program counter value identifies the instruction where the crash occurred, enabling more accurate analysis of the cause of the program crash.

[0080] Step S22, extracting function entry addresses and key code block features based on the program source code;

[0081] It's important to note that after a program is compiled and linked, each function is assigned a unique memory address, known as the function entry address. When the program calls the function, it jumps to this address to begin executing the function's code. The function entry address is a key identifier in the program's execution flow, determining where the function begins execution.

[0082] In addition, a key code block is a section of code in the program source code that has a specific function or important logic. Key code block characteristics refer to some unique properties of this code, such as code length, instruction sequence pattern, variable usage, etc.

[0083] As you can understand, the compiler and linker assign a unique memory address to each function. You can use a disassembly tool like objdump to disassemble the executable file and find the starting address of each function, which serves as the function entry point. To extract key code block features, you need to analyze the program source code. You can use methods like syntactic analysis and semantic analysis to identify key code blocks, such as those containing important computational logic or memory operations. Then, you can extract features from these code blocks, such as code length and instruction sequence patterns.

[0084] Step S23, constructing an address-code mapping according to the crash memory address, the function entry address and the key code block characteristics;

[0085] It's important to note that address-code mapping is a process that maps memory addresses to specific code within a program's source code. This mapping allows developers to find the corresponding source code location based on the memory address at runtime, helping them pinpoint the specific code causing a program crash.

[0086] It is understood that the crash memory address is compared with the function entry address. If the crash memory address is within the range of a function entry address, it indicates that the crash may have occurred within that function. For example, if the crash memory address is greater than the entry address of function A and less than the entry address of function B, then the crash may have occurred within function A. The specific code location is further determined by combining key code block features. Based on the instruction sequence pattern, code length, and other features of the key code block, a code block matching these features is searched within the function. If a matching code block is found, a correspondence is established between the crash memory address and the code block, and all established correspondences are organized into a constructed address-code map.

[0087] Step S24, determining the function name and source code line number of the crash address according to the address-code mapping, the register state, and the program counter value;

[0088] It should be noted that the function name at the crash address is the name of the function being executed when the program crashed. By analyzing the crash address and the related mapping relationship, the name of the function can be determined, which helps to understand the execution flow of the program when it crashed.

[0089] Additionally, the source code line number refers to the line number of the specific code in the program's source code. Combining the crash address and address-code mapping can determine the specific line in the source code where the crash occurred, making it easier for developers to locate and modify the code.

[0090] As can be understood, the address-code mapping is used to search for the corresponding code location based on the program counter value. The program counter value indicates the address of the instruction being executed at the time of the crash. The address-code mapping can be used to locate the source code range corresponding to this address. Further analysis can be performed in conjunction with the register status. The register status provides more information about the program execution context, such as certain registers that may store function call parameters and return addresses. By analyzing this information, the function where the crash occurred can be more accurately identified. Within the found source code range, the source code line number corresponding to the crash address is determined based on the specific code structure and address-code mapping. Based on the address-code mapping and the determined function range, the function name containing the crash address is found. Determining the function name and source code line number of the crash address precisely locates the location of the program crash. Developers can directly find the problematic line of code and function, enabling targeted debugging and repair, thereby improving the efficiency of software development and maintenance.

[0091] Step S25 : constructing an address-function-code mapping relationship according to the function name, the source code line number, and the address-code mapping.

[0092] It can be understood that by obtaining the correspondence between memory addresses and codes from the address-code mapping, associating the determined function names and source code line numbers with the corresponding memory addresses, and organizing and improving these associated information, a complete address-function-code mapping relationship can be formed.

[0093] In a feasible implementation, after step S25, the following steps may be included: searching the log content corresponding to the function name in the operation log information according to the function name to obtain the function log content; analyzing the function call sequence, function execution times, parameter passing information and key variable status in the function log content to obtain analysis results; based on the analysis results, correcting the address-function-code mapping relationship to improve the address-function-code mapping relationship.

[0094] It should be noted that function logs are log records related to a specific function name, filtered from the execution log information. These records contain various information about the function during its execution, such as the function call time, passed parameters, and return value.

[0095] Additionally, function call order refers to the order in which functions are called within a program. Understanding the function call order can help developers clarify the program's execution flow and determine whether dependencies between functions are correct. Function execution counts indicate the number of times a function is called during program execution. Abnormal function execution counts may indicate program logic errors or performance issues. Parameter passing information refers to the specific values of the parameters passed to a function during a call. Key variable states are variables within a program that have a significant impact on function implementation or program status.

[0096] Additionally, the analysis results are conclusions drawn from analyzing the function log content. These include a summary of the function call sequence, execution counts, parameter passing information, and key variable states. These results are used to determine whether the function executed normally and whether there are any factors that could cause the program to crash.

[0097] As can be understood, the function call sequence is determined by extracting the timestamp or sequence identifier of each function call from the function log content and arranging them in chronological order or by identifier. The function execution count is determined by searching for the number of occurrences of a specific function name in the function log content. This can be achieved using a counting algorithm or database statistics. Parameter passing information is extracted by locating the parameter values recorded during the function call from the function log content and organizing these values. The state of key variables is analyzed by locating the assignment and change records of key variables from the function log content to understand the variable values at different times. The analysis results of these items are organized and summarized to form the final analysis results. If the analysis results show that the call order of a function is inconsistent with the mapping record, or the function execution count is abnormal, this may indicate a problem with the mapping. The address-function-code mapping relationship is corrected to address any identified issues. If a function name in the mapping relationship does not match the actual function called, the correct function name is updated in the mapping relationship. If the line number is found to be inaccurate, it is adjusted based on the analysis results. The corrected address-function-code mapping relationship is then verified and improved. The accuracy of the mapping relationship can be ensured by re-analyzing the function log content or combining it with other debugging information. For example, in a C++ program, by analyzing the function log, it is found that the calling order of the sort_data function does not match the mapping relationship. The relevant information of the function in the mapping relationship is corrected, and then other relevant information is re-checked to ensure the correctness of the mapping relationship. By correcting and improving the address-function-code mapping relationship, the accuracy of the mapping relationship can be improved, so that when the program crashes, the function and code line where the problem occurs can be more accurately located, thereby improving the efficiency of troubleshooting and repair, and reducing the cost of software development and maintenance.

[0098] Step S30, locating the fault code in the program source code according to the address-function-code mapping relationship to obtain a program call chain and a fault code block;

[0099] It's important to note that a program's call chain is the order in which functions are called during program execution. It shows how each function is called, starting from the program's entry point, and the hierarchical relationship of these calls. By analyzing the program's call chain, you can understand the program's execution flow, identify the call path when the program crashes, and ultimately, discover the functions that may have caused the crash.

[0100] In addition, the fault code block is a code block that may have problems. It is the code area in the program source code that corresponds to the abnormal memory address. By analyzing the logic of this code block, it is checked whether there is an error that causes the program to crash.

[0101] It is understandable that, based on the previously constructed address-function-code mapping relationship, the functions and code lines in the mapping relationship are mapped to the program source code. Starting from the function call stack address at the time of the crash, the mapping relationship is used to gradually determine the function corresponding to each address in the call stack, thereby reconstructing the program's call chain. The code lines corresponding to the abnormal memory address are found from the mapping relationship, and the code area where these code lines are located is determined as the faulty code block. The obtained program call chain and code block are sorted and analyzed to prepare for the subsequent determination of the cause of the crash. By locating the program call chain and code block, it is possible to clearly understand the execution process and key code areas when the program crashed, which helps to deeply analyze the cause of the crash and improve the accuracy of fault location.

[0102] In a feasible implementation, step S30 may include steps S31 to S34:

[0103] Step S31, determining the crash source code location corresponding to the crash memory address according to the address-function-code mapping relationship;

[0104] It's important to note that the crash memory address refers to the memory address being accessed or operated upon when the program crashed. When a program exception occurs, such as accessing illegal memory or out-of-bounds memory, this address records the specific memory location where the crash occurred. The crash source code location is the specific location in the program source code corresponding to the crash memory address, including information such as the file, function, and line number.

[0105] Step S32, obtaining the corresponding crash function body and calling context according to the crash source code location;

[0106] It should be noted that the crash function body refers to the complete code portion of the function including the crash source code location. The crash function body includes the function definition, parameters, local variables, and all execution statements within the function.

[0107] In addition, the calling context refers to the environment information when a function is called during program execution. It includes the function that calls the function (the caller), the parameter values passed to the function, and the program state at the time of the function call. The calling context helps understand the circumstances under which the function was called.

[0108] It can be understood that based on the function name and file information in the crash source code location, the corresponding function definition is found in the program source code and identified as the crashing function body. To obtain the calling context, the program's runtime log, debugging information, or debugging tools can be analyzed. From this information, the name of the function that called the crashing function, the parameter values passed, and the program state at the time can be found. For example, debugging tools can be used to view the function call stack to understand the function call order and caller; the runtime log can be used to obtain information about the parameters passed to the function.

[0109] Step S33, rebuilding the program call chain according to the crashed function body and the calling context;

[0110] It's important to note that a program call chain is the order in which functions are called during program execution. It shows how each function is called sequentially, forming a chain of function calls, starting from the program entry point. For example, if a program starts with the main function, which calls funcA, which in turn calls funcB, the program call chain is main->funcA->funcB.

[0111] It is understandable that the function information that called the crashed function, that is, the caller, is obtained from the crashed function body and the calling context. Starting from the caller, continue to find the caller of the caller, and so on, and continue to backtrack the function call relationship. Repeat the above steps until you backtrack to the entry function of the program (usually the main function). Arrange all functions in the order of calling to reconstruct the program call chain. Reconstructing the program call chain can clearly show the function call process when the program crashes, help developers understand the execution path of the program, find the function call link that may cause the crash, and thus more accurately locate the problem.

[0112] Step S34: obtaining a function call address according to the program call chain, and mapping the function call address and the program source code to obtain a fault code block.

[0113] As you can understand, for each function name in the program call chain, the corresponding function call address is found using debugging information, mapped to the program source code, and the code area associated with the program crash is identified from the mapping results, defined as the faulty code block. By identifying the faulty code block, developers can focus on the code area that may have caused the program crash, reducing the scope of troubleshooting and improving the efficiency of fixing program crashes.

[0114] Step S40: locating the core dump crash cause based on the fault code block, the program call chain, and the running log information.

[0115] It should be noted that the core dump crash cause is the specific factor that causes the program to crash and generate a core dump file. It may be a logical error in the code, a memory management problem, etc. Locating the core dump crash cause is the ultimate purpose of analyzing the core dump file.

[0116] It is understandable that logical reasoning and judgment can be made by comprehensively analyzing the faulty code block, program call chain, and runtime log information. If there is a possibility of a pointer reference in the code block, and the runtime log also records information that the relevant variable was not correctly initialized, and the call chain indicates that there may be problems with the function call before the operation, then it can be more certain that these factors are the cause of the program crash. For example, when analyzing the core dump file of a file processing program, there is an operation on the file pointer in the faulty code block, the program call chain shows that the file read operation was directly performed after the file open function call, and the runtime log records information about the file open failure. Combining this information, it can be determined that the program crashed because the read operation was performed before the file was successfully opened. By integrating multiple aspects of information to locate the cause of the core dump crash, the problem can be identified more comprehensively and accurately, providing strong support for developers to fix program errors and reducing the cost of software development and system maintenance.

[0117] In a feasible implementation, step S40 may include steps S41 to S44:

[0118] Step S41, obtaining the abnormal call path and the upstream function call relationship according to the fault code block and the program call chain;

[0119] It should be noted that an abnormal call path is a function call sequence or path in the program call chain that does not conform to normal logic due to some abnormal situation. For example, under normal circumstances, funcA calls funcB, but due to an exception, funcA skips funcB and directly calls funcC. This is an abnormal call path.

[0120] In addition, the upstream function call relationship refers to other functions that call the function where the current fault code block is located in the program call chain and the call relationship between them.

[0121] It can be understood that the function containing the faulty code block is located in the program call chain. By analyzing the sequence of the program call chain, the position of the function containing the faulty code block in the call chain is found. The calling order and conditions of this function in the call chain are examined. Compared with the normal program logic, whether there are any unexpected calling situations is determined. If so, it is determined to be an abnormal call path. The program call chain is traced back to find other functions that call the function containing the faulty code block and the calling relationship between them is determined, that is, the upstream function call relationship.

[0122] Step S42: searching the operation log information for fault log content according to the abnormal call path and the upstream function call relationship;

[0123] It is understandable that, based on the function name and calling order in the abnormal call path, relevant log records are searched in the running log information. By matching the function call information recorded in the log, the part related to the abnormal call path is filtered out. Combined with the upstream function call relationship, the search scope is further expanded. Find the relevant logs of the upstream function that calls the function where the fault code block is located, including the call time of these functions, the parameters passed in, and other information. The retrieved log records are sorted and filtered, and irrelevant information is removed. Only the log content closely related to the abnormal call path and the upstream function call relationship is retained to obtain the fault log content.

[0124] Step S43: Analyze the fault log content to obtain the fault variable status and function execution behavior;

[0125] It's important to note that the fault variable state refers to the values of key variables at the time of a program crash. Function execution behavior refers to the various aspects of a function's performance during execution, including information such as the function's call time, execution duration, return value, and whether or not an exception was thrown. Analyzing function execution behavior can help determine whether the function executes as expected and whether any anomalies occur.

[0126] It is understandable that the fault log content is parsed to extract the variable information recorded therein. The log is checked to see if there are any records of variable assignments, modifications, or other operations. The values of key variables at the time of the fault are determined, that is, the fault variable states. Function execution-related information is extracted from the fault log content, including the function call time, execution duration, and return value. By comparing the function execution behavior under normal circumstances, it is determined whether the function has an abnormality.

[0127] Step S44: locating the core dump crash cause according to the fault variable state, the function execution behavior, the abnormal call path, and the upstream function call relationship.

[0128] It's understandable that a comprehensive analysis of the fault variable state examines whether the fault variable's value conforms to normal logic. If the variable value is abnormal, further analysis is conducted on the variable's role and impact within the program to determine whether it caused the program crash. This judgment is then combined with function execution behavior. Check whether the function's execution time and return value are normal. If the function execution behavior is abnormal, analyze the possible cause. Consider the abnormal call path. Analyze whether the abnormal call path disrupts the normal program logic, resulting in the skipping of necessary initialization or processing steps. Based on the upstream function call relationship, check whether the upstream function call correctly passes parameters and performs necessary error handling. Combining the above analysis results, logical reasoning and judgment are performed to determine the most likely cause of the core dump crash. For example, if comprehensive analysis reveals that the abnormal fault variable state is due to the abnormal call path skipping the variable initialization step, and the abnormal function execution behavior is due to the use of uninitialized variables, the core dump crash can be determined to be caused by uninitialized variables. By integrating multiple aspects of information to locate the cause of the core dump crash, the problem can be more comprehensively and accurately identified, providing developers with clear guidance for fixing program errors and reducing software development and system maintenance costs.

[0129] In a feasible implementation, step S41 may include the steps of: analyzing the memory exception operations in the fault code block, the memory exception operations including pointer access, memory allocation and release, and array indexing; and determining the exception call path and upstream function call relationship of the memory exception operation based on the memory exception operation and the program call chain.

[0130] It should be noted that memory exceptions refer to situations where the operation on memory does not conform to normal logic or causes errors during program execution. Common memory exceptions include problems with pointer access, memory allocation and release, and array indexing. A pointer is a variable that stores memory addresses. Pointer access exceptions may be dereferencing a null pointer, that is, trying to access a pointer that does not point to a valid memory address; or accessing memory that has been released (dangling pointer). In a program, functions such as malloc, calloc, and realloc are usually used for memory allocation, and the free function is used for memory release. Memory allocation and release exceptions may be memory leaks, that is, memory is allocated but not released in time; or the same block of memory is released repeatedly. For example, calling free(ptr) twice in a row to release the same block of memory. An array is a set of continuous memory spaces, and array elements are accessed through indexes. Array index exceptions are usually array out-of-bounds access, that is, the index used exceeds the valid range of the array. For example, an array intarr[5] with a length of 5 is defined; but using arr

[10] to access array elements will cause the array to be out of bounds.

[0131] It is understandable that the fault code block is analyzed line by line to identify the code involving pointer access, memory allocation and release, and array indexing. Syntax analysis can be used to find statements in the code that use pointers, memory allocation and release functions, and array indexing. For pointer access, check whether the pointer is initialized before use and whether there is a dereference operation on a null pointer or a dangling pointer. For example, find a dereference operation such as *ptr in the code and then check whether ptr has been initialized correctly. For memory allocation and release operations, check whether the call to the memory allocation function is successful and whether there is a memory leak or repeated release. For example, check whether the return value of the malloc function is NULL and whether there is code that repeatedly calls the free function. Analyze array index operations and check whether the index value is within the valid range of the array. This can be determined by comparing the defined length of the array with the index value used. For example, for the array intarr

[10] ;, check whether the index used in the code is between 0 and 9. Record all memory exception operations found and their location in the fault code block. For example, record that the dereference operation of the null pointer occurs on line 5 of the fault code block.

[0132] This embodiment provides a method for locating the cause of a core dump crash, which solves the technical problem of being difficult to locate the cause of a program crash in the absence of a symbol table by obtaining program source code and operation log information, and parsing the core dump file to obtain crash status information. By constructing an address-function-code mapping relationship, this embodiment can accurately locate the fault code in the program source code and obtain a program call chain and a fault code block. By comprehensively analyzing the fault code block, the program call chain, and the operation log information, this embodiment achieves accurate positioning of the cause of the core dump crash. This method not only breaks through the limitations of traditional reliance on symbol tables, but also improves the efficiency and accuracy of fault diagnosis, reduces the cost of software development and system maintenance, and achieves the beneficial effect of improving software quality and maintenance efficiency.

[0133] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 2 Before step S10, the core dump crash cause location method further includes steps S01 to S04:

[0134] Step S01, when compiling a program in a test environment, enabling a debug information generation instruction to generate an initial executable file;

[0135] It's important to note that a test environment is specifically designed for testing programs. It simulates actual program execution scenarios, but allows for more detailed observation and control of the program. Within the test environment, developers can use various debugging tools to verify program functionality and identify potential errors.

[0136] Debug information generation directives are specific commands or options used during the compilation process to instruct the compiler to generate additional debugging information. This debugging information includes function names, variable names, source code line numbers, and more, helping developers debug their programs when problems arise. In the GCC compiler, the most common debug information generation directive is the -g option.

[0137] The initial executable file is a compiled file containing machine language code and debugging information. It can be run on the appropriate operating system and hardware environment. This file not only contains the code and data required to run the program, but also contains debugging information to facilitate debugging.

[0138] As you can understand, developers place their prepared program source code in a test environment. This test environment is already configured with the appropriate compilation tools, such as a compiler and linker. When using the compilation tools for compilation, developers add debug information generation instructions. Upon receiving the compilation command, the compiler begins compiling the source code. During the compilation process, in addition to converting the source code into machine language code, it also collects and records debug information such as function names, variable names, and source code line numbers based on the debug information generation instructions. Upon receiving the compilation command, the compiler begins compiling the source code, generating an initial executable file containing both machine language code and debug information.

[0139] Step S02, separating the symbol table from the initial executable file to obtain a debugging executable file;

[0140] It's important to note that a debug executable is an executable file created by removing the symbol table from the original executable. This file can still be run in the appropriate environment, but it doesn't contain the complete symbol table information. This reduces the file size and also protects the program's intellectual property to a certain extent. For example, the objcopy tool can be used to remove the symbol table from the original executable to generate a debug executable.

[0141] It is understood that the separated debug executable file is checked to ensure that it still functions properly. This debug executable file can be run in a test environment to verify that the program functions normally and that there are no issues caused by the separation of the symbol table. Separating the symbol table from the original executable file reduces the size of the executable file, making it easier to deploy and use in a production environment. Furthermore, the separated symbol table can be stored separately and used in conjunction with the debug executable file when debugging is required, improving program security and manageability.

[0142] Step S03, performing version identification management on the debugging executable file to obtain a test executable file and a production executable file;

[0143] It's important to note that version identification management is the process of identifying, recording, and managing different versions of a program. This helps developers better control and manage versions by clearly identifying features, functional changes, and release dates for each version. Common version identification methods include using version numbers, such as 1.0 and 1.1.

[0144] Separately, a test executable is an executable file specifically used for testing within the version identification management process. It has the same functionality as the production executable, but may include special testing code or configuration, allowing developers to thoroughly test the program in a test environment. A production executable is the executable file intended to run in an actual production environment. It undergoes rigorous testing and optimization to ensure stable and efficient operation in a production environment. Production executables typically remove some testing-related code and configuration to improve performance and security.

[0145] It is understandable that the version identification scheme is determined, for example, by using a semantic version number, which consists of a major version number, a minor version number, and a revision number, such as 1.0.0. The version number of the current debug executable file is determined according to the development progress and functional changes of the program. Based on the debug executable file, a test executable file is created. You can copy the debug executable file and make some configuration modifications for testing, such as setting the log level to detailed mode, adding test-related code, etc. Based on the debug executable file, a production executable file is created. The debug executable file is optimized to remove test-related code and configuration, such as removing redundant log output code, test interfaces, etc. Then the production executable file is marked with the same version number to ensure the functional consistency of the test executable file and the production executable file.

[0146] Step S04: monitoring and recording memory operations during the running of the test executable file and the production executable file.

[0147] It is understandable that appropriate memory monitoring tools, such as Valgrind and AddressSanitizer (ASAN), can be selected. These tools can monitor memory operations in real time while the program is running. Recorded memory operation information should be analyzed regularly to check for problems such as memory leaks and illegal memory access. If problems are found, they should be repaired promptly to improve the stability and reliability of the program. Monitoring and recording memory operations during the execution of test and production executable files can promptly detect memory-related problems, avoid memory leaks, illegal memory access, and other situations that may cause program crashes or performance degradation during program operation, improve program quality and stability, and ensure the normal operation of the production environment.

[0148] This embodiment provides a method for locating the cause of a core dump crash, which generates an initial executable file by enabling debug information generation instructions when compiling a program in a test environment, and further separates the symbol table from the initial executable file to obtain a debug executable file. This technical problem of facilitating debugging and reducing the size of deployment files while protecting intellectual property rights is solved. By performing version identification management on the debug executable file, a test executable file and a production executable file are obtained, ensuring the consistency and functional stability of program versions deployed in different environments. By monitoring and recording memory operations during the operation of the test executable file and the production executable file, memory-related problems can be discovered and resolved in a timely manner, thereby improving the stability and reliability of the program. These measures achieve the beneficial effects of effectively managing and optimizing program versions in development, testing and production environments, as well as improving program operation quality and maintenance efficiency. At the same time, they also provide more accurate and convenient basic data support for subsequent core dump crash cause location.

[0149] For example, to help understand the implementation process of the core dump crash cause location method obtained by combining this embodiment with the above embodiment 1, please refer to Figure 3 , Figure 3 This article provides a brief flowchart of the method for locating the cause of a core dump crash. Specifically:

[0150] The process is divided into four main phases. The first is the pre-release phase, which includes three steps: C / C++ program memory testing, version management, and symbol table preservation. C / C++ program memory testing detects program memory issues. Version management ensures consistency between the test and production executables. Symbol table preservation involves adding the -g option during compile time in the test environment to generate debug information or using the objcopy tool to strip debug symbols into separate files. The next phase is after the coredump file is generated, which involves obtaining information from multiple sources, including coredump file parsing, code file analysis, and runtime log collection. Coredump file parsing extracts key data such as memory information, register status, and program counter value. Code file analysis obtains the source code file corresponding to the coredump and analyzes the code structure and function call relationships. Runtime log collection collects log information during program execution. The third phase involves constructing address mapping relationships, which is divided into code feature-based address mapping and runtime information-assisted mapping. The former analyzes the characteristics of function entry points and key code blocks in the source code and matches them with memory addresses in the coredump file. The latter further corrects and improves the address mapping relationship based on information from runtime logs. The last stage is the fault location analysis, which includes abnormal code block location, call chain analysis and comprehensive judgment of multi-source information. Abnormal code block location maps the detected abnormal memory address to the specific code block in the source code. Call chain analysis reconstructs the program's call chain and determines the call path when the program crashes. Comprehensive judgment of multi-source information combines code analysis, call chain analysis and information in the operation log to make a comprehensive judgment on the cause of the fault.

[0151] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the core dump crash cause location method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0152] This application also provides a core dump crash cause location device, please refer to Figure 4 , the core dump crash cause locating device includes:

[0153] The acquisition module 10 is used to obtain program source code and operation log information, and parse the core dump file to obtain crash status information;

[0154] A construction module 20, configured to construct an address-function-code mapping relationship using the crash status information and the program source code;

[0155] A mapping module 30 is configured to locate the fault code in the program source code according to the address-function-code mapping relationship, and obtain a program call chain and a fault code block;

[0156] The positioning module 40 is used to locate the core dump crash cause based on the fault code block, the program call chain and the running log information.

[0157] The core dump crash cause location device provided by this application, which utilizes the core dump crash cause location method of the above-mentioned embodiment, can solve the technical problem of being unable to effectively locate the cause of a program crash in a core dump file in the absence of a symbol table. Compared with the prior art, the beneficial effects of the core dump crash cause location device provided by this application are the same as those of the core dump crash cause location method provided by the above-mentioned embodiment, and the other technical features of the core dump crash cause location device are the same as those disclosed in the above-mentioned embodiment method, and are not further described here.

[0158] In one embodiment, the construction module 20 is further used to extract the crash memory address, register status and program counter value based on the crash status information; extract the function entry address and key code block features based on the program source code; construct an address-code mapping based on the crash memory address, the function entry address and the key code block features; determine the function name and source code line number of the crash address based on the address-code mapping, the register status and the program counter value; and construct an address-function-code mapping relationship based on the function name, the source code line number and the address-code mapping.

[0159] In one embodiment, the construction module 20 is further used to retrieve the log content corresponding to the function name in the operation log information according to the function name to obtain the function log content; analyze the function call sequence, function execution times, parameter passing information and key variable status in the function log content to obtain analysis results; based on the analysis results, correct the address-function-code mapping relationship to improve the address-function-code mapping relationship.

[0160] In one embodiment, the mapping module 30 is further used to determine the crash source code location corresponding to the crash memory address based on the address-function-code mapping relationship; obtain the corresponding crash function body and calling context based on the crash source code location; reconstruct the program call chain based on the crash function body and the calling context; obtain the function call address based on the program call chain, and map the function call address and the program source code to obtain a fault code block.

[0161] In one embodiment, the positioning module 40 is further used to obtain the abnormal call path and the upstream function call relationship based on the fault code block and the program call chain; retrieve the fault log content in the operation log information based on the abnormal call path and the upstream function call relationship; analyze the fault log content to obtain the fault variable status and function execution behavior; and locate the cause of the core dump crash based on the fault variable status, the function execution behavior, the abnormal call path and the upstream function call relationship.

[0162] In one embodiment, the positioning module 40 is also used to analyze the memory abnormal operations in the fault code block, and the memory abnormal operations include pointer access, memory allocation and release, and array indexing; based on the memory abnormal operations and the program call chain, determine the abnormal call path and upstream function call relationship where the memory abnormal operation is located.

[0163] In one embodiment, the construction module 20 is further used to enable debugging information generation instructions when compiling a program in a test environment to generate an initial executable file; separate the symbol table from the initial executable file to obtain a debugging executable file; perform version identification management on the debugging executable file to obtain a test executable file and a production executable file; and monitor and record memory operations during the execution of the test executable file and the production executable file.

[0164] The present application provides a core dump crash cause locating device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the core dump crash cause locating method in the above-mentioned embodiment one.

[0165] Reference below Figure 5 , which shows a schematic structural diagram of a core dump crash cause location device suitable for implementing an embodiment of the present application. The core dump crash cause location device in the embodiment of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5The core dump crash cause location device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0166] like Figure 5 As shown, the core dump crash cause locating device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a ROM (Read Only Memory) 1002 or a program loaded from a storage device 1003 into a RAM (Random Access Memory) 1004. Various programs and data required for the operation of the core dump crash cause locating device are also stored in the RAM 1004. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the core dump crash cause location device to communicate with other devices wirelessly or by wire to exchange data. Although the core dump crash cause location device is shown with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have instead.

[0167] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0168] The core dump crash cause location device provided by this application, using the core dump crash cause location method of the above-mentioned embodiment, can solve the technical problem of being unable to effectively locate the cause of a program crash in a core dump file in the absence of a symbol table. Compared with the prior art, the beneficial effects of the core dump crash cause location device provided by this application are the same as the beneficial effects of the core dump crash cause location method provided by the above-mentioned embodiment, and the other technical features of the core dump crash cause location device are the same as those disclosed in the method of the previous embodiment, and are not further described here.

[0169] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0170] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0171] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, a computer program) stored thereon, wherein the computer-readable program instructions are used to execute the core dump crash cause locating method in the above embodiment.

[0172] The computer-readable storage medium provided in this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (Erasable Programmable Read Only Memory or flash memory, EPROM), optical fiber, CD-ROM (CD-Read Only Memory, portable compact disk read-only memory), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium can be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0173] The computer-readable storage medium may be included in the core dump crash cause location device; or may exist independently without being assembled into the core dump crash cause location device.

[0174] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the core dump crash cause locating device, the core dump crash cause locating device: obtains program source code and operation log information, and parses the core dump file to obtain crash status information; constructs an address-function-code mapping relationship through the crash status information and the program source code; locates the fault code in the program source code according to the address-function-code mapping relationship, and obtains a program call chain and a fault code block; and locates the core dump crash cause according to the fault code block, the program call chain and the operation log information.

[0175] The computer program code for performing the operations of the present application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a LAN (Local Area Network) or a WAN (Wide Area Network), or can be connected to an external computer (e.g., using an Internet service provider to connect via the Internet).

[0176] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0177] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0178] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., a computer program) for executing the above-mentioned core dump crash cause locating method, which can solve the technical problem of being unable to effectively locate the cause of the program crash in the Coredump file in the absence of a symbol table. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the core dump crash cause locating method provided by the above-mentioned embodiment, and will not be described in detail here.

[0179] The present application also provides a computer program product, comprising a computer program, which implements the steps of the above-mentioned core dump crash cause locating method when executed by a processor.

[0180] The computer program product provided by this application can solve the technical problem of being unable to effectively locate the cause of a program crash in a core dump file when a symbol table is missing. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as those of the core dump crash cause location method provided in the above embodiment, and will not be elaborated here.

[0181] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for locating the cause of a core dump crash, characterized in that: The method comprises: Obtain program source code and running log information, and parse core dump files to obtain crash status information; Constructing an address-function-code mapping relationship through the crash status information and the program source code; Locating the fault code in the program source code according to the address-function-code mapping relationship to obtain a program call chain and a fault code block; The cause of the core dump crash is located based on the fault code block, the program call chain, and the running log information.

2. The method according to claim 1, wherein The step of constructing an address-function-code mapping relationship using the crash status information and the program source code includes: Extracting the crash memory address, register status, and program counter value according to the crash status information; Extracting function entry addresses and key code block features based on the program source code; Constructing an address-code mapping according to the crash memory address, the function entry address, and the key code block characteristics; Determine the function name and source code line number of the crash address based on the address-code mapping, the register status, and the program counter value; An address-function-code mapping relationship is constructed according to the function name, the source code line number, and the address-code mapping.

3. The method according to claim 2, wherein After the step of constructing an address-function-code mapping relationship according to the function name, the source code line number, and the address-code mapping, the method further includes: Retrieving the log content corresponding to the function name in the operation log information according to the function name to obtain the function log content; Analyze the function call sequence, function execution times, parameter passing information, and key variable status in the function log content to obtain analysis results; Based on the analysis result, the address-function-code mapping relationship is modified to improve the address-function-code mapping relationship.

4. The method according to claim 1, wherein The step of locating the fault code in the program source code according to the address-function-code mapping relationship to obtain the program call chain and the fault code block includes: Determining the crash source code location corresponding to the crash memory address based on the address-function-code mapping relationship; According to the crash source code location, obtain the corresponding crash function body and calling context; Reconstructing a program call chain according to the crashed function body and the calling context; A function call address is obtained according to the program call chain, and the function call address and the program source code are mapped to obtain a fault code block.

5. The method according to claim 1, wherein The step of locating the cause of the core dump crash according to the fault code block, the program call chain, and the running log information includes: Obtaining an abnormal call path and an upstream function call relationship based on the fault code block and the program call chain; Retrieving fault log content from the operation log information according to the abnormal call path and the upstream function call relationship; Analyze the fault log content to obtain fault variable status and function execution behavior; The core dump crash cause is located according to the fault variable state, the function execution behavior, the abnormal call path, and the upstream function call relationship.

6. The method according to claim 5, wherein The step of obtaining the abnormal call path and the upstream function call relationship according to the fault code block and the program call chain includes: Analyzing abnormal memory operations in the fault code block, wherein the abnormal memory operations include pointer access, memory allocation and release, and array indexing; According to the memory exception operation and the program call chain, an exception call path where the memory exception operation is located and an upstream function call relationship are determined.

7. The method according to claim 1, wherein Before the steps of obtaining program source code and operation log information, and parsing the core dump file to obtain crash status information, the following steps are also included: When compiling the program in the test environment, enable the debug information generation instruction to generate the initial executable file; Separating the symbol table from the initial executable file to obtain a debugging executable file; Performing version identification management on the debugging executable file to obtain a test executable file and a production executable file; Memory operations during the running of the test executable file and the production executable file are monitored and recorded.

8. A core dump crash cause location device, characterized in that: The device comprises: The acquisition module is used to obtain program source code and running log information, and parse the core dump file to obtain crash status information; A construction module, configured to construct an address-function-code mapping relationship based on the crash status information and the program source code; A mapping module, configured to locate the fault code in the program source code according to the address-function-code mapping relationship, and obtain a program call chain and a fault code block; A positioning module is used to locate the cause of the core dump crash based on the fault code block, the program call chain and the running log information.

9. A core dump crash cause location device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the core dump crash cause locating method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the core dump crash cause locating method according to any one of claims 1 to 7 are implemented.

Images