Efficient kernel dump problem analyzing and positioning method and device

Abstract

The invention provides an efficient kernel dump problem analyzing and positioning method and device, and belongs to the field of computer software. The method comprises the following steps: acquiring a kernel dump file through a Kexec tool; analyzing the obtained core dump file of the kernel by using a crash tool; analyzing the basic information output by the crash report, calling a stack by a function, and checking the reason causing the system crash; comparing the stack contents in the plurality of core dump files, and calculating the similarity among the stack contents to find the same abnormal point or call sequence; the similarity is compared with a preset threshold value, and if the similarity is higher than the threshold value, it is indicated that further anomaly detection is needed. According to the scheme, the analysis and positioning efficiency of the kernel dump problem is improved, the troubleshooting time is shortened, rapid identification and positioning of abnormal points are realized, and the accuracy of anomaly detection is improved.

Description

Technical Field

[0001] The invention belongs to the field of computer software, and in particular relates to an efficient kernel core dump problem analysis and positioning method and device. Background Art

[0002] The present invention is an improvement on the traditional kernel core dump problem analysis and location technology. Traditional kernel core dump problem analysis usually locates the problem by manually analyzing the dump file, viewing the basic information and the function call stack. This method has the following problems and challenges:

[0003] Tedious and time-consuming: Traditional methods require manual analysis of dump files step by step, checking a large amount of basic information and function call stacks, which is time-consuming and labor-intensive.

[0004] Easy to miss: Since the dump file contains a lot of information, manual analysis can easily overlook or miss some important abnormal points or call sequences.

[0005] Low reliability: The results of manual analysis are affected by personal experience and ability, and there is a bias in subjective judgment, so the reliability of the analysis results is not high.

[0006] Limitations: Traditional methods usually only analyze a single dump file, making it difficult to find common anomalies or call sequences between different dump files.

[0007] The present invention aims to overcome the above-mentioned problems of the traditional method and provide an efficient and automated kernel core dump problem analysis and positioning method, which compares the stack contents in multiple dump files and calculates the similarity between them to find the same abnormal points or call sequences. At the same time, the present invention also combines register value analysis and parameter transfer situation analysis to further improve the accuracy and reliability of abnormality detection. Through the technical solution of the present invention, problems in kernel core dump files can be quickly and accurately located, and the stability and reliability of the system can be improved. Summary of the invention

[0008] In view of this, the present invention provides an efficient kernel core dump problem analysis and location method, comprising:

[0009] Step 1: Get the kernel core dump file through the kexec tool;

[0010] Step 2: Use the crash tool to analyze the obtained kernel core dump file; analyze the basic information output by the crash report, the function call stack, and check the cause of the system crash;

[0011] Step 3, compare the stack contents in multiple core dump files and calculate the similarity between them to find the same abnormal points or call sequences;

[0012] Step 4, comparing the similarity with a preset threshold. If the similarity is higher than the threshold, it is necessary to analyze the register, stack, parameter order and parameter arrangement order to determine whether there is an abnormality according to different CPU architectures.

[0013] In particular, the step 1 specifically includes: checking whether kexec is available, and if not available, installing the kexec tool and loading the kexec module, and confirming again whether kexec is available.

[0014] In particular, the step 2 specifically includes: using a crash tool to open a kernel dump file and analyzing basic information output by a crash report; analyzing the function call sequence in a function call stack and checking the function call path that causes panic.

[0015] In particular, in step 3, calculating the stack content similarity specifically includes:

[0016]

[0017] Wherein, NCC represents the Normalized Cross-Correlation coefficient, which is used to measure the similarity between two vectors; pp1 and pp2 represent two stack vectors, which represent the stack contents in different core dump files respectively; n represents the length of the stack vector, that is, the number of elements in the stack; j represents the index in the stack, which is used to traverse each element in the stack; pp1(j) and pp2(j) represent the elements with index j in the stack vector, which represent the function call sequence or other related information in the stack; and Represent the means of the stack vectors pp1 and pp2 respectively.

[0018] In particular, in step 4, it is necessary to analyze the registers, stack, parameter order and parameter arrangement order according to different CPU architectures to determine whether there is an abnormality, and detect the abnormality through the following algorithm:

[0019]

[0020] Among them: if the abnormal detection score Score is less than or equal to the set threshold, it means that there is an abnormality; if the abnormal detection score Score is greater than the set threshold, it means that the parameter transfer is normal; in the algorithm, R expected Indicates the expected number of parameters in registers; R actual Indicates the number of parameters in the actual register; S expected Indicates the expected number of parameters in the stack; S actual Indicates the number of parameters in the actual stack; Oexpected Indicates the expected order of parameters in registers; O actual Indicates the order of parameters in the actual register; P expected Indicates the expected order of parameters in the stack; P actual Indicates the order of parameters in the actual stack; R max , S max , O max , P max They represent the maximum possible values ​​of registers, stacks, parameter order, and parameter arrangement order respectively; w1, w2, w3, and w4 represent weight coefficients, which are used to adjust the contribution ratio of each factor in the total score.

[0021] The present invention also discloses an efficient kernel core dump problem analysis and positioning device, comprising:

[0022] The kernel dump file acquisition module is used to obtain the kernel core dump file through the kexec tool;

[0023] The kernel dump file analysis module is used to analyze the obtained kernel core dump file using the crash tool; analyze the basic information output by the crash report, the function call stack, and check the cause of the system crash;

[0024] The stack comparison module is used to compare the stack contents in multiple core dump files and calculate the similarity between them to find the same abnormal points or call sequences;

[0025] The anomaly detection module is used to compare the similarity with a preset threshold. If the similarity is higher than the threshold, it is necessary to analyze the register, stack, parameter order and parameter arrangement order to determine whether an anomaly exists according to different CPU architectures.

[0026] Beneficial effects:

[0027] Through the technical solution of the present invention:

[0028] 1. Improved the efficiency of analyzing and locating kernel core dump problems. By using the kexec tool to obtain kernel core dump files and combining them with the crash tool to analyze the dump files, the efficiency of analyzing and locating kernel core dump problems is effectively improved, and the troubleshooting time is shortened.

[0029] 2. Rapid identification and location of abnormal points is achieved. By comparing the stack contents in multiple core dump files and calculating the similarity between them, the same abnormal points or call sequences can be quickly identified and located, which helps to quickly locate system abnormalities.

[0030] 3. Improved the accuracy of anomaly detection. By comparing the stack contents of multiple dump files and performing similarity comparison based on pre-set thresholds, anomalies can be detected more accurately, the false alarm rate can be reduced, and the accuracy of anomaly detection can be improved.

[0031] 4. The timeliness of exception handling is improved. Once a system crash occurs, the technical solution of the present invention can be used to quickly obtain and analyze the dump file, so that the exception can be discovered and handled in time, reducing the impact of system exceptions and improving the stability and reliability of the system.

[0032] 5. The comprehensiveness of system fault analysis is improved. The technical solution of the present invention can not only analyze the basic information and function call stack output by the crash report, but also further analyze the register value and function parameter transfer situation, comprehensively analyze the system fault from multiple angles, and provide more comprehensive reference information for troubleshooting. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A schematic diagram of a process flow of an efficient kernel core dump problem analysis and location method in the present invention;

[0034] Figure 2 A schematic diagram of an efficient kernel core dump problem analysis and location device. DETAILED DESCRIPTION

[0035] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0036] The present invention provides an efficient kernel core dump problem analysis and location method, comprising:

[0037] Step 1: Obtain the kernel core dump file through the kexec tool, which includes the following steps:

[0038] Check whether kexec is available. First, make sure the kexec tool is installed in the system. If it is not installed, you can install it through the package manager (such as apt, yum, etc.).

[0039] Load the kexec module: In Linux system, kexec is a kernel module, which needs to be loaded first. You can use the following command to load the kexec module: modprobekexec;

[0040] Check if kexec is available: Run the following command to check if the system is correctly configured and ready to use kexec: Set kernel dump parameters: Set kernel dump parameters through the kexec tool, including the path, format, and other related parameters of the dump file. You can use the following command to set kernel dump parameters:

[0041] kexec-p--command-line="crashkernel=256M"--initrd= / boot / initrd.img-<kernel_version> / boot / vmlinuz-<kernel_version>

[0042] Step 2: Use the crash tool to analyze the obtained kernel core dump file; analyze the basic information output by the crash report, the function call stack, and view the function call path that causes panic;

[0043] Open the core dump file:

[0044] Use the crash tool to open the core dump file. The command is usually crash <vmlinux> <vmcore>,in <vmlinux>is the vmlinux file that matches the kernel version. <vmcore>Is a core dump file.

[0045] Analysis of basic information:

[0046] Analyze the basic information output by the crash report, which can help you understand the background and environment of the system crash. Basic information may include kernel version, system boot time, memory usage, number of CPUs, etc. You can use different options in the crash command to obtain this information, such as the bt (backtrace) command to display stack information, the ps command to display process information, and the cpu command to display CPU information.

[0047] Analyze the function call stack:

[0048] Use the bt (backtrace) command to analyze the function call stack. This will show the function call path that caused the panic and the call relationship. You can view the order of function calls in the call stack to understand why the system crashed. Usually, start analyzing from the bottom function and then look up the call path until you find the function that caused the system crash.

[0049] View the function call path that causes panic:

[0050] In the function call stack, find the function call path that caused the panic. This path is usually displayed at the top of the stack or the location of the last function call. Analyzing this function call path can help you determine the specific cause of the system crash, such as error handling in the kernel, problems with device drivers, or abnormal conditions in other system components.

[0051] Step 3 compares the stack contents in multiple core dump files and calculates the similarity between them to find the same abnormal points or call sequences; Step 2 provides the analysis results of a single dump file, while Step 3 further mines the common features of abnormal points or call sequences based on the comparison of multiple dump files.

[0052] Identification and location of abnormal points: The analysis results in step 2 can provide a data basis for step 3. By comparing the similarity of the stack contents of multiple dump files, the same abnormal points or call sequences can be identified. This helps to more accurately locate abnormalities in the system and further analyze the characteristics and causes of the abnormal points.

[0053] Further screening of anomaly detection: The similarity value calculated in step 3 can be used as an indicator for anomaly detection. If the similarity is higher than the preset threshold, it may indicate that the stack content similarity between multiple dump files is high and the system anomalies are relatively consistent. In this case, these anomalies can be further analyzed to improve the accuracy and reliability of anomaly detection.

[0054] In step 3, calculating the stack content similarity specifically includes:

[0055]

[0056] Wherein, NCC represents the Normalized Cross-Correlation coefficient, which is used to measure the similarity between two vectors; pp1 and pp2 represent two stack vectors, which represent the stack contents in different core dump files respectively; n represents the length of the stack vector, that is, the number of elements in the stack; j represents the index in the stack, which is used to traverse each element in the stack; pp1(j) and pp2(j) represent the elements with index j in the stack vector, which represent the function call sequence or other related information in the stack; and Represent the means of the stack vectors pp1 and pp2 respectively.

[0057] Step 4, comparing the similarity with a preset threshold value, if the similarity is higher than the threshold value, it indicates that further abnormality detection is required; the need to further detect abnormalities in step 4 includes: further analyzing whether there are abnormalities in registers, stacks, parameter order, and parameter arrangement order according to different CPU architectures, and specifically detecting abnormalities through the following algorithm:

[0058]

[0059] Among them: If the anomaly detection score Score is less than or equal to the set threshold, it means that there is an anomaly; if ScoreScore is greater than the set threshold, it means that the parameter transfer is normal; in the algorithm, R expected Indicates the expected number of parameters in registers; R actual Indicates the number of parameters in the actual register; S expected Indicates the expected number of parameters in the stack; S actual Indicates the number of parameters in the actual stack; O expected Indicates the expected order of parameters in registers; O actual Indicates the order of parameters in the actual register; P expected Indicates the expected order of parameters in the stack; P actual Indicates the order of parameters in the actual stack; R max , S max , O max , P max They represent the maximum possible values ​​of registers, stacks, parameter order, and parameter arrangement order respectively; w1, w2, w3, and w4 represent weight coefficients, which are used to adjust the contribution ratio of each factor in the total score.

[0060] The present invention also discloses an efficient kernel core dump problem analysis and positioning device, such as Figure 2 As shown, including:

[0061] The kernel dump file acquisition module is used to obtain the kernel core dump file through the kexec tool;

[0062] Check whether kexec is available. First, make sure the kexec tool is installed in the system. If it is not installed, you can install it through the package manager (such as apt, yum, etc.).

[0063] Load the kexec module: In Linux system, kexec is a kernel module, which needs to be loaded first. You can use the following command to load the kexec module: modprobekexec;

[0064] Check if kexec is available: Run the following command to check if the system is correctly configured and ready to use kexec: Set kernel dump parameters: Set kernel dump parameters through the kexec tool, including the path, format, and other related parameters of the dump file. You can use the following command to set kernel dump parameters: kexec -p --command-line = "crashkernel = 256M" --initrd = / boot / initrd.img -<kernel_vers ion> / boot / vmlinuz-<kernel_version> ;

[0065] The kernel dump file analysis module is used to analyze the obtained kernel core dump file using the crash tool; analyze the basic information and function call stack output by the crash report to check the cause of the system crash; analyze the basic information and function call stack output by the crash report to check the function call path that caused the panic;

[0066] Open the core dump file:

[0067] Use the crash tool to open the core dump file. The command is usually crash <vmlinux> <vmcore>,in <vmlinux>is the vmlinux file that matches the kernel version. <vmcore>Is a core dump file.

[0068] Analysis of basic information:

[0069] Analyze the basic information output by the crash report, which can help you understand the background and environment of the system crash. Basic information may include kernel version, system boot time, memory usage, number of CPUs, etc. You can use different options in the crash command to obtain this information, such as the bt (backtrace) command to display stack information, the ps command to display process information, and the cpu command to display CPU information.

[0070] Analyze the function call stack: Use the bt (backtrace) command to analyze the function call stack. This will show the function call path that caused the panic and the call relationship. You can view the order of function calls in the call stack to understand why the system crashed. Generally, start the analysis from the bottom function and then look up the call path until you find the function that caused the system crash.

[0071] View the function call path that caused the panic: In the function call stack, find the function call path that caused the panic. This path is usually displayed at the top of the stack or the location of the last function call. Analyzing this function call path can help you determine the specific cause of the system crash, such as error handling in the kernel, problems with device drivers, or abnormal conditions in other system components.

[0072] The stack comparison module is used to compare the stack contents in multiple core dump files and calculate the similarity between them to find the same abnormal points or call sequences; in the stack comparison module, the stack content similarity is calculated, specifically including:

[0073]

[0074] Wherein, NCC represents the Normalized Cross-Correlation coefficient, which is used to measure the similarity between two vectors; pp1 and pp2 represent two stack vectors, which represent the stack contents in different core dump files respectively; n represents the length of the stack vector, that is, the number of elements in the stack; j represents the index in the stack, which is used to traverse each element in the stack; pp1(j) and pp2(j) represent the elements with index j in the stack vector, which represent the function call sequence or other related information in the stack; and Represent the means of the stack vectors pp1 and pp2 respectively.

[0075] The anomaly detection module is used to compare the similarity with a preset threshold. If the similarity is higher than the threshold, it indicates that further anomaly detection is required. Further anomaly detection includes: further analyzing whether there are anomalies in registers, stacks, parameter order, and parameter arrangement order according to different CPU architectures. The anomaly is detected specifically through the following algorithm:

[0076]

[0077] Among them: If the anomaly detection score Score is less than or equal to the set threshold, it means that there is an anomaly; if ScoreScore is greater than the set threshold, it means that the parameter transfer is normal; in the algorithm, R expected Indicates the expected number of parameters in registers; R actual Indicates the number of parameters in the actual register; S expected Indicates the expected number of parameters in the stack; S actual Indicates the number of parameters in the actual stack; O expected Indicates the expected order of parameters in registers; O actual Indicates the order of parameters in the actual register; P expected Indicates the expected order of parameters in the stack; P actual Indicates the order of parameters in the actual stack; R max , S max , O max , P max They represent the maximum possible values ​​of registers, stacks, parameter order, and parameter arrangement order respectively; w1, w2, w3, and w4 represent weight coefficients, which are used to adjust the contribution ratio of each factor in the total score.

[0078] The solution of the present invention improves the analysis and positioning efficiency of kernel core dump problems: by using the kexec tool to obtain the kernel core dump file, and combining the crash tool to analyze the dump file, the analysis and positioning efficiency of the kernel core dump problem is effectively improved, and the troubleshooting time is shortened.

[0079] Rapid identification and location of abnormal points is achieved: by comparing the stack contents in multiple core dump files and calculating the similarity between them, the same abnormal points or call sequences can be quickly identified and located, which helps to quickly locate system abnormalities.

[0080] Improved anomaly detection accuracy: By comparing the stack contents of multiple dump files and performing similarity comparisons based on pre-set thresholds, anomalies can be detected more accurately, the false alarm rate can be reduced, and the accuracy of anomaly detection can be improved.

[0081] Improved timeliness of exception handling: Once a system crash occurs, the technical solution of the present invention can be used to quickly obtain and analyze dump files, and exceptions can be discovered and handled in a timely manner, reducing the impact of system exceptions and improving system stability and reliability.

[0082] Improved comprehensiveness of system fault analysis: The technical solution of the present invention can not only analyze the basic information and function call stack output by the crash report, but also further analyze the register value and function parameter transfer situation, comprehensively analyze the system fault from multiple angles, and provide more comprehensive reference information for troubleshooting.

[0083] In summary, the above are only preferred embodiments of the present invention and are not intended to limit the protection scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

[0084] It is obvious to those skilled in the art that the embodiments of the present invention are not limited to the details of the above exemplary embodiments, and that the embodiments of the present invention can be implemented in other specific forms without departing from the spirit or basic features of the embodiments of the present invention. Therefore, no matter from which point of view, the embodiments should be regarded as exemplary and non-restrictive, and the scope of the embodiments of the present invention is limited by the attached claims rather than the above description, so it is intended to include all changes that fall within the meaning and scope of the equivalent elements of the claims in the embodiments of the present invention. Any figure mark in the claims should not be regarded as limiting the claims involved. In addition, it is obvious that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units, modules or devices stated in the system, device or terminal claims can also be implemented by the same unit, module or device through software or hardware. The words first, second, etc. are used to indicate names, and do not indicate any particular order.

[0085] Finally, it should be noted that the above implementation modes are only used to illustrate the technical solutions of the embodiments of the present invention and are not intended to limit them. Although the embodiments of the present invention have been described in detail with reference to the above preferred implementation modes, those skilled in the art should understand that the technical solutions of the embodiments of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the embodiments of the present invention.< / vmcore> < / vmlinux> < / vmcore> < / vmlinux> < / vmcore> < / vmlinux> < / vmcore> < / vmlinux>

Claims

1. An efficient kernel core dump problem analysis and location method, characterized in that: include: Step 1: Get the kernel core dump file through the kexec tool; Step 2: Use the crash tool to analyze the obtained kernel core dump file; analyze the basic information output by the crash report, the function call stack, and check the cause of the system crash; Step 3, compare the stack contents in multiple core dump files and calculate the similarity between them to find the same abnormal points or call sequences; Step 4, comparing the similarity with a preset threshold. If the similarity is higher than the threshold, it is necessary to analyze the register, stack, parameter order and parameter arrangement order to determine whether there is an abnormality according to different CPU architectures.

2. The efficient kernel core dump problem analysis and location method according to claim 1 is characterized in that: The step 1 specifically includes: checking whether kexec is available, if not available, installing the kexec tool and loading the kexec module, and confirming again whether kexec is available.

3. The efficient kernel core dump problem analysis and location method according to claim 2 is characterized in that: The step 2 specifically includes: using a crash tool to open a kernel dump file and analyzing basic information output by a crash report; analyzing the function call sequence in a function call stack and checking the function call path that causes panic.

4. The efficient kernel core dump problem analysis and location method according to claim 3 is characterized in that: In step 3, calculating the stack content similarity specifically includes: Wherein, NCC represents the Normalized Cross-Correlation coefficient, which is used to measure the similarity between two vectors; pp1 and pp2 represent two stack vectors, which represent the stack contents in different core dump files respectively; n represents the length of the stack vector, that is, the number of elements in the stack; j represents the index in the stack, which is used to traverse each element in the stack; pp1(j) and pp2(j) represent the elements with index j in the stack vector, which represent the function call sequence or other related information in the stack; and Represent the means of the stack vectors pp1 and pp2 respectively.

5. The efficient kernel core dump problem analysis and location method according to claim 4 is characterized in that: In step 4, it is necessary to analyze the registers, stack, parameter order and parameter arrangement order according to different CPU architectures to determine whether there is an exception, including detecting the exception through the following algorithm: Among them: if the abnormal detection score Score is less than or equal to the set threshold, it means that there is an abnormality; if the abnormal detection score Score is greater than the set threshold, it means that the parameter transfer is normal; in the algorithm, R expected Indicates the expected number of parameters in registers; R actual Indicates the number of parameters in the actual register; S expected Indicates the expected number of parameters in the stack; S actual Indicates the number of parameters in the actual stack; O expected Indicates the expected order of parameters in registers; O actual Indicates the order of parameters in the actual register; P expected Indicates the expected order of parameters in the stack; P actual Indicates the order of parameters in the actual stack; R max , S max , O max , P max They represent the maximum possible values ​​of registers, stacks, parameter order, and parameter arrangement order respectively; w1, w2, w3, and w4 represent weight coefficients, which are used to adjust the contribution ratio of each factor in the total score.

6. An efficient kernel core dump problem analysis and location device, characterized in that: include: The kernel dump file acquisition module is used to obtain the kernel core dump file through the kexec tool; The kernel dump file analysis module is used to analyze the obtained kernel core dump file using the crash tool; analyze the basic information output by the crash report, the function call stack, and check the cause of the system crash; The stack comparison module is used to compare the stack contents in multiple core dump files and calculate the similarity between them to find the same abnormal points or call sequences; The anomaly detection module is used to compare the similarity with a preset threshold. If the similarity is higher than the threshold, it is necessary to analyze the register, stack, parameter order and parameter arrangement order to determine whether an anomaly exists according to different CPU architectures.

Images