Deadlock fault analysis method and computing device

Abstract

The embodiment of the invention provides a deadlock fault analysis method and computing equipment. The method comprises the following steps: a computing device runs a watchdog service, and calls a callback function to obtain lock information when monitoring that an operating system has a fault; and the computing device saves the lock information to the log file so as to analyze the deadlock fault according to the lock information in the log file. Or the computing device inquires the memory mirror image file, obtains the lock information and displays the lock information. Wherein the memory mirror image file is obtained by storing and processing memory data when an operating system breaks down when a kernel crash dump service monitors that the operating system breaks down; the lock information comprises data structure information of the lock, an application sequence in which the at least one CPU applies to use the lock, and call stack information corresponding to the at least one CPU. According to the method provided by the embodiment of the invention, the lock information acquisition efficiency and accuracy are improved.

Description

Technical Field

[0001] The present application relates to the technical field of computing devices, and in particular to a deadlock failure analysis method and computing device. Background Art

[0002] In the related art, the watchdog service can trigger the kernel crash dump service (kdump service) when detecting an operating system failure, and save the memory data at the time of the operating system failure as a memory image file (vmcore file). The operation and maintenance engineer needs to manually use an analysis program (such as a crash tool) to analyze the memory image file to obtain the lock information.

[0003] In the related art, operation and maintenance engineers are required to manually use analysis programs to obtain lock information based on memory image files with huge amounts of data, which may have problems with low efficiency and accuracy. Summary of the invention

[0004] The embodiments of the present application provide a deadlock fault analysis method and a computing device, which improve the efficiency and accuracy of obtaining lock information.

[0005] In a first aspect, an embodiment of the present application provides a deadlock fault analysis method, comprising:

[0006] Running the watchdog service, when detecting a failure of the operating system, calling the callback function to obtain lock information; the lock information includes: data structure information of the lock, the application order of at least one central processing unit CPU to apply for the lock, and call stack information corresponding to at least one CPU;

[0007] The lock information is saved in a log file so that the deadlock failure can be analyzed based on the lock information in the log file.

[0008] In this solution, the computing device can run the watchdog service to monitor the operating system for faults, and call the callback function when the operating system is detected to have a fault, so that the callback function obtains the lock information. On the one hand, compared with the related art, the operation and maintenance engineer needs to manually use the analysis program to obtain the lock information based on the memory image file with a large amount of data, which may have the problem of low efficiency and accuracy. The method of the embodiment of the present application adopts the method of registering the callback function on the call chain of the watchdog service. In the case of a fault in the operating system, in response to the call of the watchdog service, the callback function can be run to obtain the lock information, thereby improving the efficiency and accuracy of obtaining the lock information. On the other hand, the callback function of the embodiment of the present application is to obtain the lock information based on the call of the watchdog service in the case of a fault in the operating system. The method of the embodiment of the present application does not need to obtain the lock information when the operating system does not have a fault, thereby reducing the resource overhead of the operating system and avoiding affecting the performance of the operating system. On the other hand, in the method of the embodiment of the present application, the callback function can be used as a separate module. When the callback function needs to be used to obtain the lock information, the callback function is registered on the notification chain of the watchdog service, thereby realizing the architecture decoupling and ensuring the portability of the callback function. On the other hand, compared with the related art, it is necessary to use the kernel crash dump service (kdump service) with poor reliability to generate a memory image file, and it is necessary to use an analysis program (such as a crash tool) to obtain and analyze the memory image file that may include sensitive information, resulting in poor security and poor reliability. The method of the embodiment of the present application can use the callback function registered to the notification chain of the watchdog service to automatically obtain lock information, thereby improving the efficiency and security of obtaining lock information.

[0009] In one implementation, obtaining lock information includes:

[0010] Read the target register to obtain the lock address; the target register is the register storing the lock address;

[0011] According to the lock address, obtain the lock data structure information;

[0012] Determine the application order based on the lock data structure information;

[0013] According to the application order, the call stack information corresponding to at least one CPU is obtained.

[0014] In this solution, the computing device can run the callback function, read the target register (the register storing the lock address), obtain the lock address, and obtain the data structure information of the lock according to the lock address. The computing device can run the callback function, determine the application order according to the data structure information of the lock, and obtain the call stack information corresponding to at least one CPU according to the application order. In this way, the callback function can obtain the lock information, which improves the efficiency and accuracy of obtaining the lock information.

[0015] In one implementation, before acquiring the lock information, the method further includes:

[0016] Acquire call stack information corresponding to the target CPU; wherein the call stack information corresponding to the target CPU includes call information of at least one function; the target CPU is the CPU running when the operating system fails;

[0017] It is determined that the calling information of at least one function contains the calling information of the target function; the target function is the calling function used to acquire the lock.

[0018] In this solution, the computing device can determine that the lock information acquisition condition is satisfied when it is determined that the call information of the target function exists in the call information of at least one function, that is, it is determined that the operating system failure is caused by the lock. The computing device can obtain the lock information when it is determined that the lock information acquisition condition is satisfied. By setting the lock information acquisition condition in the above manner, the utilization rate of the lock information can be improved.

[0019] In one implementation, determining the application order according to the data structure information of the lock includes:

[0020] In the data structure information, the first CPU is determined; the first CPU is the last CPU to apply for the lock;

[0021] Determine whether the first CPU holds the lock;

[0022] If so, the application sequence is determined to include only the identification of the first CPU;

[0023] If not, at least one CPU search operation is performed, and the application order is determined according to the first CPU and the CPU obtained by the search operation.

[0024] In this solution, when the first CPU (the last CPU to apply for the lock) occupies the lock, the computing device can determine that only the first CPU has applied for the lock, that is, the application order only includes the identifier of the first CPU. When the first CPU does not occupy the lock, the computing device can determine that there are other CPUs that have applied for the lock, and the computing device can perform at least one CPU search process to obtain the application order. In this way, the identifier of each CPU in the application order can be accurately determined, which improves the accuracy of determining the application order.

[0025] In one implementation, performing at least one CPU lookup operation includes:

[0026] According to the address information of the data structure corresponding to the i-th CPU, the i+1-th CPU is obtained; the i+1-th CPU is the CPU that applied for the lock before the i-th CPU; the data structure corresponding to the i+1-th CPU includes the address information of the data structure corresponding to the i-th CPU;

[0027] Determine whether the i+1th CPU holds the lock;

[0028] If yes, it is determined that the order in which the i+1th CPU applies for the lock is before the ith CPU, and the CPU search operation is terminated;

[0029] If not, it is determined that the order in which the i+1th CPU applies for the lock is before the i-th CPU.

[0030] In this scheme, based on the data structure corresponding to the i+1th CPU, including the address information of the data structure corresponding to the i-th CPU, the computing device can perform a search process according to the address information of the data structure corresponding to the i-th CPU to obtain the i+1th CPU. When the i+1th CPU occupies the lock, the computing device can determine that the order in which the i+1th CPU applies to use the lock is before the i-th CPU, and end the CPU search operation; when the i+1th CPU does not occupy the lock, the computing device can determine that the order in which the i+1th CPU applies to use the lock is before the i-th CPU. Through the above method, accurate search of each CPU that applies to use the lock is achieved, that is, the accuracy of determining the application order is improved.

[0031] In one implementation, the data structure information of the lock includes a lock state and a waiting state; the method further includes:

[0032] When the lock state indicates that the lock is occupied and the waiting state indicates that there is a CPU that has applied for use but does not occupy the lock, it is determined that a deadlock fault exists.

[0033] In this solution, the computing device can determine that a deadlock fault exists when the lock state indicates that the lock is occupied and the waiting state indicates that there is a CPU that has applied for use and does not occupy the lock. Through the above method, the accuracy of determining whether the operating system has a deadlock fault is improved. In other words, the accuracy of determining the fault type (deadlock fault) of the operating system is improved.

[0034] In one implementation, the method further includes:

[0035] Determine the second CPU according to the application order, and determine the process corresponding to the second CPU according to the second CPU, and determine that the process corresponding to the second CPU has an abnormality, and the second CPU is the first CPU to apply for the lock; or,

[0036] Determine call stack information corresponding to a second CPU based on call stack information corresponding to at least one CPU, determine function call relationships of a process corresponding to the second CPU based on the call stack information corresponding to the second CPU, and determine that there is an abnormality in the function call relationship of the process corresponding to the second CPU; or

[0037] According to the call stack information corresponding to the at least one CPU, a function call relationship of a process corresponding to the at least one CPU is determined, and it is determined that an abnormality exists in the function call relationship of the process corresponding to the at least one CPU.

[0038] In this solution, the computing device can determine that the process corresponding to the second CPU has an abnormality based on the lock information, or determine that the function call relationship of the process corresponding to the second CPU has an abnormality, or determine that the function call relationship of the process corresponding to at least one CPU has an abnormality. In this way, the accuracy of deadlock fault analysis is improved.

[0039] In a second aspect, an embodiment of the present application provides a method for analyzing a deadlock fault, including:

[0040] Query the memory image file to obtain lock information; the memory image file is a kernel crash dump service, and when the operating system fails, the memory data at the time of the operating system failure is saved and processed; the lock information includes: lock data structure information, the application order of at least one central processing unit CPU to apply for the use of the lock, and the call stack information corresponding to at least one CPU;

[0041] Display lock information to analyze deadlock faults based on the lock information.

[0042] In this solution, the computing device can obtain the lock information by querying the memory image file. On the one hand, compared with the related art, which requires the operation and maintenance engineer to manually use the analysis program and use multiple commands to obtain the lock information based on the memory image file with a large amount of data, which may have problems of low efficiency and accuracy, the method of the embodiment of the present application can directly and automatically query the memory image file to obtain the lock information, thereby improving the efficiency, accuracy, and security of determining the lock information.

[0043] In one implementation, querying the memory image file to obtain lock information includes:

[0044] Query the memory image file to determine the target register in the target CPU; the target CPU is the CPU that runs when the operating system fails; the target register is the register that stores the lock address;

[0045] Read the target register to get the lock address;

[0046] According to the lock address, obtain the lock data structure information;

[0047] Determine the application order based on the lock data structure information;

[0048] According to the application order, query the memory image file to obtain the call stack information corresponding to at least one CPU.

[0049] In this solution, the computing device can determine the target register by querying the memory image file. The computing device can read the target register, obtain the lock address, and obtain the data structure information of the lock according to the lock address. The computing device can determine the application order according to the data structure information of the lock, and query the memory image file according to the application order to obtain the call stack information corresponding to at least one CPU. Through the above method, the orderly search of the memory image file is realized to quickly find the lock information, thereby improving the efficiency and accuracy of obtaining the lock information.

[0050] In one implementation, before acquiring the lock information, the method further includes:

[0051] Acquire call stack information corresponding to the target CPU; wherein the call stack information corresponding to the target CPU includes call information of at least one function; the target CPU is the CPU running when the operating system fails;

[0052] It is determined that the calling information of at least one function contains the calling information of the target function; the target function is the calling function used to acquire the lock.

[0053] In this solution, the computing device can determine that the lock information acquisition condition is satisfied when it is determined that the call information of the target function exists in the call information of at least one function, that is, it is determined that the operating system failure is caused by the lock. The computing device can obtain the lock information when it is determined that the lock information acquisition condition is satisfied. By setting the lock information acquisition condition in the above manner, the utilization rate of the lock information can be improved.

[0054] In one implementation, determining the application order according to the data structure information of the lock includes:

[0055] In the data structure information, the first CPU is determined; the first CPU is the last CPU to apply for the lock;

[0056] Determine whether the first CPU holds the lock;

[0057] If so, the application sequence is determined to include only the identification of the first CPU;

[0058] If not, at least one CPU search operation is performed, and the application order is determined according to the first CPU and the CPU obtained by the search operation.

[0059] In this solution, when the first CPU (the last CPU to apply for the lock) occupies the lock, the computing device can determine that only the first CPU has applied for the lock, that is, the application order only includes the identifier of the first CPU. When the first CPU does not occupy the lock, the computing device can determine that there are other CPUs that have applied for the lock, and the computing device can perform at least one CPU search process to obtain the application order. In this way, the identifier of each CPU in the application order can be accurately determined, which improves the accuracy of determining the application order.

[0060] In one implementation, performing at least one CPU lookup operation includes:

[0061] According to the address information of the data structure corresponding to the i-th CPU, the i+1-th CPU is obtained; the i+1-th CPU is the CPU that applied for the lock before the i-th CPU; the data structure corresponding to the i+1-th CPU includes the address information of the data structure corresponding to the i-th CPU;

[0062] Determine whether the i+1th CPU holds the lock;

[0063] If yes, it is determined that the order in which the i+1th CPU applies for the lock is before the ith CPU, and the CPU search operation is terminated;

[0064] If not, it is determined that the order in which the i+1th CPU applies for the lock is before the i-th CPU.

[0065] In this scheme, based on the data structure corresponding to the i+1th CPU, including the address information of the data structure corresponding to the i-th CPU, the computing device can perform a search process according to the address information of the data structure corresponding to the i-th CPU to obtain the i+1th CPU. When the i+1th CPU occupies the lock, the computing device can determine that the order in which the i+1th CPU applies to use the lock is before the i-th CPU, and end the CPU search operation; when the i+1th CPU does not occupy the lock, the computing device can determine that the order in which the i+1th CPU applies to use the lock is before the i-th CPU. Through the above method, accurate search of each CPU that applies to use the lock is achieved, that is, the accuracy of determining the application order is improved.

[0066] In one implementation, the data structure information of the lock includes a lock state and a waiting state; the method further includes:

[0067] When the lock state indicates that the lock is occupied and the waiting state indicates that there is a CPU that has applied for use but does not occupy the lock, it is determined that a deadlock fault exists.

[0068] In this solution, the computing device can determine that a deadlock fault exists when the lock state indicates that the lock is occupied and the waiting state indicates that there is a CPU that has applied for use and does not occupy the lock. Through the above method, the accuracy of determining whether the operating system has a deadlock fault is improved. In other words, the accuracy of determining the fault type (deadlock fault) of the operating system is improved.

[0069] In one implementation, the method further includes:

[0070] Determine the second CPU according to the application order, and determine the process corresponding to the second CPU according to the second CPU, and determine that the process corresponding to the second CPU has an abnormality, and the second CPU is the first CPU to apply for the lock; or,

[0071] Determine call stack information corresponding to a second CPU based on call stack information corresponding to at least one CPU, determine function call relationships of a process corresponding to the second CPU based on the call stack information corresponding to the second CPU, and determine that there is an abnormality in the function call relationship of the process corresponding to the second CPU; or

[0072] According to the call stack information corresponding to the at least one CPU, a function call relationship of a process corresponding to the at least one CPU is determined, and it is determined that an abnormality exists in the function call relationship of the process corresponding to the at least one CPU.

[0073] In this solution, the computing device can determine that the process corresponding to the second CPU has an abnormality based on the lock information, or determine that the function call relationship of the process corresponding to the second CPU has an abnormality, or determine that the function call relationship of the process corresponding to at least one CPU has an abnormality. In this way, the accuracy of deadlock fault analysis is improved.

[0074] In a third aspect, an embodiment of the present application provides a deadlock fault analysis device, including:

[0075] The watchdog service is used to call the callback function to obtain lock information when a failure of the operating system is detected; the lock information includes: data structure information of the lock, the application order of at least one central processing unit CPU to apply for the use of the lock, and the call stack information corresponding to at least one CPU;

[0076] The callback function is used to save the lock information to the log file so as to analyze the deadlock failure according to the lock information in the log file.

[0077] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0078] In one implementation, the callback function includes:

[0079] The lock data structure analysis module is used to read the target register and obtain the lock address; the target register is the register storing the lock address;

[0080] The lock data structure analysis module is used to obtain the lock data structure information according to the lock address;

[0081] The lock queue analysis module is used to determine the application order based on the lock data structure information;

[0082] The waiting lock CPU call stack recording module is used to obtain the call stack information corresponding to at least one CPU according to the application order.

[0083] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0084] In one implementation, the method further includes:

[0085] A scenario analysis module, used to obtain call stack information corresponding to a target CPU; wherein the call stack information corresponding to the target CPU includes call information of at least one function; the target CPU is the CPU running when a failure occurs in the operating system;

[0086] The scenario analysis module is further used to determine that the calling information of at least one function contains calling information of a target function; the target function is a calling function used to acquire a lock.

[0087] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0088] In one implementation, the lock queue analysis module is specifically used to:

[0089] In the data structure information, the first CPU is determined; the first CPU is the last CPU to apply for the lock;

[0090] Determine whether the first CPU holds the lock;

[0091] If so, the application sequence is determined to include only the identification of the first CPU;

[0092] If not, at least one CPU search operation is performed, and the application order is determined according to the first CPU and the CPU obtained by the search operation.

[0093] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0094] In one implementation, the lock queue analysis module is specifically used to:

[0095] According to the address information of the data structure corresponding to the i-th CPU, the i+1-th CPU is obtained; the i+1-th CPU is the CPU that applied for the lock before the i-th CPU; the data structure corresponding to the i+1-th CPU includes the address information of the data structure corresponding to the i-th CPU;

[0096] Determine whether the i+1th CPU holds the lock;

[0097] If yes, it is determined that the order in which the i+1th CPU applies for the lock is before the ith CPU, and the CPU search operation is terminated;

[0098] If not, it is determined that the order in which the i+1th CPU applies for the lock is before the i-th CPU.

[0099] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0100] In one implementation, the data structure information of the lock includes a lock state and a waiting state; the callback function also includes:

[0101] The fault analysis module is used to determine that a deadlock fault exists when the lock state indicates that the lock is occupied and the waiting state indicates that there is a CPU that has applied for use but does not occupy the lock.

[0102] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0103] In one implementation, the fault analysis module is further configured to:

[0104] Determine the second CPU according to the application order, and determine the process corresponding to the second CPU according to the second CPU, and determine that the process corresponding to the second CPU has an abnormality, and the second CPU is the first CPU to apply for the lock; or,

[0105] Determine call stack information corresponding to a second CPU based on call stack information corresponding to at least one CPU, determine function call relationships of a process corresponding to the second CPU based on the call stack information corresponding to the second CPU, and determine that there is an abnormality in the function call relationship of the process corresponding to the second CPU; or

[0106] According to the call stack information corresponding to the at least one CPU, a function call relationship of a process corresponding to the at least one CPU is determined, and it is determined that an abnormality exists in the function call relationship of the process corresponding to the at least one CPU.

[0107] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0108] In a fourth aspect, an embodiment of the present application provides a lock analysis plug-in for:

[0109] Query the memory image file to obtain lock information; the memory image file is a kernel crash dump service, and when the operating system fails, the memory data at the time of the operating system failure is saved and processed; the lock information includes: lock data structure information, the application order of at least one central processing unit CPU to apply for the use of the lock, and the call stack information corresponding to at least one CPU;

[0110] Display lock information to analyze deadlock faults based on the lock information.

[0111] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0112] In one implementation, the lock analysis plug-in includes:

[0113] The lock data structure analysis module is used to query the memory image file and determine the target register in the target CPU; the target CPU is the CPU that runs when the operating system fails; the target register is the register that stores the lock address;

[0114] The lock data structure analysis module is used to read the target register and obtain the lock address;

[0115] The lock data structure analysis module is used to obtain the lock data structure information according to the lock address;

[0116] The lock queue analysis module is used to determine the application order based on the lock data structure information;

[0117] The waiting lock CPU call stack recording module is used to query the memory image file according to the application order and obtain the call stack information corresponding to at least one CPU.

[0118] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0119] In one implementation, the method further includes:

[0120] A scenario analysis module, used to obtain call stack information corresponding to a target CPU; wherein the call stack information corresponding to the target CPU includes call information of at least one function; the target CPU is the CPU running when a failure occurs in the operating system;

[0121] The scenario analysis module is further used to determine that the calling information of at least one function contains calling information of a target function; the target function is a calling function used to acquire a lock.

[0122] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0123] In one implementation, the lock queue analysis module is specifically used to:

[0124] In the data structure information, the first CPU is determined; the first CPU is the last CPU to apply for the lock;

[0125] Determine whether the first CPU holds the lock;

[0126] If so, determining the application order includes only the identification of the first CPU;

[0127] If not, at least one CPU search operation is performed, and the application order is determined according to the first CPU and the CPU obtained by the search operation.

[0128] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0129] In one implementation, the lock queue analysis module is specifically used to:

[0130] According to the address information of the data structure corresponding to the i-th CPU, the i+1-th CPU is obtained; the i+1-th CPU is the CPU that applied for the lock before the i-th CPU; the data structure corresponding to the i+1-th CPU includes the address information of the data structure corresponding to the i-th CPU;

[0131] Determine whether the i+1th CPU holds the lock;

[0132] If yes, it is determined that the order in which the i+1th CPU applies for the lock is before the ith CPU, and the CPU search operation is terminated;

[0133] If not, it is determined that the order in which the i+1th CPU applies for the lock is before the i-th CPU.

[0134] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0135] In one implementation, the data structure information of the lock includes a lock state and a waiting state; the lock analysis plug-in further includes:

[0136] The fault analysis module is used to determine that a deadlock fault exists when the lock state indicates that the lock is occupied and the waiting state indicates that there is a CPU that has applied for use but does not occupy the lock.

[0137] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0138] In one implementation, the fault analysis module is further configured to:

[0139] Determine the second CPU according to the application order, and determine the process corresponding to the second CPU according to the second CPU, and determine that the process corresponding to the second CPU has an abnormality, and the second CPU is the first CPU to apply for the lock; or,

[0140] Determine call stack information corresponding to a second CPU based on call stack information corresponding to at least one CPU, determine function call relationships of a process corresponding to the second CPU based on the call stack information corresponding to the second CPU, and determine that there is an abnormality in the function call relationship of the process corresponding to the second CPU; or

[0141] According to the call stack information corresponding to the at least one CPU, a function call relationship of a process corresponding to the at least one CPU is determined, and it is determined that an abnormality exists in the function call relationship of the process corresponding to the at least one CPU.

[0142] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0143] In a fifth aspect, an embodiment of the present application provides a computing device, including:

[0144] A processor, and a memory communicatively connected to the processor;

[0145] Memory is used to store computer executable instructions;

[0146] The processor is used to execute the computer-executable instructions stored in the memory to implement the method of the first aspect or the second aspect.

[0147] The computing device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0148] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the method of the first aspect.

[0149] When the computer-executable instructions in the computer-readable storage medium provided in the embodiment of the present application are executed by the processor, the technical solution shown in the above method embodiment can be implemented. The implementation principle and beneficial effects are similar and will not be repeated here.

[0150] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which is used to implement the method of the first aspect when the computer program is executed by a processor.

[0151] When the computer program in the computer program product provided in the embodiment of the present application is executed by a processor, the technical solution shown in the above method embodiment can be implemented. The implementation principle and beneficial effects are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0152] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the following is a brief introduction to the drawings required for use in the embodiments or the related technical descriptions. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0153] Figure 1a A schematic diagram of the architecture of a computing device provided in an embodiment of the present application;

[0154] Figure 1b A schematic diagram of a software architecture provided for an embodiment of the present application;

[0155] Figure 2a A flowchart of a first embodiment of a deadlock fault analysis method provided in an embodiment of the present application;

[0156] Figure 2b A schematic diagram of a scenario for obtaining lock information provided in an embodiment of the present application;

[0157] Figure 2c A schematic diagram of data structure information of a lock provided in an embodiment of the present application;

[0158] Figure 2d A schematic diagram of the principle of a search operation provided in an embodiment of the present application;

[0159] Figure 3a A flowchart of a second embodiment of a deadlock fault analysis method provided in an embodiment of the present application;

[0160] Figure 3b A second schematic diagram of a scenario for obtaining lock information provided in an embodiment of the present application;

[0161] Figure 3c A schematic diagram of the interaction between the analysis program and the lock analysis plug-in;

[0162] Figure 3d A schematic diagram of the built-in commands of the analysis program;

[0163] Figure 4 A schematic diagram of the structure of a deadlock fault analysis device provided in an embodiment of the present application;

[0164] Figure 5 A schematic diagram of the structure of the lock analysis plug-in provided in an embodiment of the present application;

[0165] Figure 6 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0166] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments made by ordinary technicians in this field under the enlightenment of the embodiments belong to the scope of protection of the present application.

[0167] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0168] Glossary:

[0169] Deadlock: A state in which a process in an operating system cannot continue to run. In one implementation, in a multi-process concurrent environment, when two or more processes are waiting for each other due to competition for resources, the operating system may deadlock.

[0170] Kernel crash (panic): A serious error occurs inside the operating system and an unexpected situation occurs that requires immediate shutdown. This situation is usually caused by kernel bugs, device failures, etc. If a kernel panic occurs, the operating system will not be able to work normally and needs to be restarted.

[0171] Crash tool: An open source command line tool for analyzing memory data when the operating system crashes.

[0172] Notification chain: A notification chain is a data structure, usually a list or linked list, used to store a set of function pointers of callback functions. When a specific event occurs, the notification chain will call the callback function through the function pointer of the callback function in sequence.

[0173] To facilitate understanding, first combine Figure 1a An architecture of a computing device involved in an embodiment of the present application is described.

[0174] Figure 1a A schematic diagram of the architecture of a computing device provided in an embodiment of the present application.

[0175] like Figure 1a As shown, the computing device 10 may include a processor 101, a memory 102, and a hard disk 103. The memory 102 and the hard disk 103 may be electrically connected to the processor 101. It should be noted that the processor 101 may run an operating system.

[0176] The processor 101 may be a central processing unit (CPU) or other components with processing capabilities. The CPU is the computing and control core of the computing device 10 and is the final execution unit for information processing and program execution. The CPU is a large-scale integrated circuit composed of an arithmetic unit, a controller, a register, etc. Its main task is to process and process various data.

[0177] The memory 102 is also called internal memory or main memory, and is installed in a memory slot on the motherboard of the computing device. The memory can be used to store the operation data of the processor. For example, the memory can be a random access memory (Random Access Memory, RAM), a dynamic random access memory (Dynamic Random Access Memory, DRAM), a synchronous dynamic random access memory (Synchronous Dynamic Random Access Memory, SDRAM), a dual inline memory module (Dual Inline Memory Modules, DIMM), a persistent memory (Persistent Memory, PMEM), or a double data rate synchronous dynamic random access memory (Double Data Rate, DDR), etc.

[0178] The hard disk 103 is the main storage device of the computing device 10 and can be a solid state disk or a mechanical hard disk.

[0179] It should also be noted that the computing device 10 may be a terminal (mobile phone, computer, etc.) or a server.

[0180] Figure 1b A software architecture diagram provided in the embodiment of the present application. Figure 1b As shown, the figure shows two levels, namely kernel state and user state. Kernel state and user state are two operating states of the operating system, and their main difference lies in the different access rights.

[0181] Kernel state, also known as privileged state, refers to the execution mode with the highest permissions in a computing device. Kernel state is mainly used to handle system-level tasks, such as device drivers and file management.

[0182] like Figure 1b As shown, the kernel state includes a watchdog service 20 and a lock information analysis program 30. In addition, the kernel state may also include a kernel crash dump service 40 and a memory image file 50. Wherein, the watchdog service 20 may call the lock information analysis program 30 when a failure of the operating system is detected, so that the lock information analysis program 30 obtains the lock information and saves the lock information to a log file (the log file is stored in the hard disk 103). Wherein, the lock information includes: data structure information of the lock, the application order of at least one CPU applying for the use of the lock, and the call stack information corresponding to at least one CPU.

[0183] User state, also known as non-privileged state, refers to an execution mode with lower permissions in a computing device, usually used by applications. User state is mainly used to execute applications. Since user state corresponds to lower permissions, applications running in user state can only execute some characteristic instructions and access some restricted data to prevent malicious applications from causing damage to computing devices.

[0184] like Figure 1b As shown, the user state includes a lock analysis plug-in 60. Among them, the lock analysis plug-in 60 can query the memory image file 50, obtain the lock information, and display the lock information. Among them, the memory image file 50 is the kernel crash dump service 40, which is obtained by saving and processing the memory data when the operating system fails when a failure is detected in the operating system. It should be noted that the lock information includes: the data structure information of the lock, the application order of at least one CPU applying for the use of the lock, and the call stack information corresponding to at least one CPU. It should also be noted that the kernel crash dump service 40 is triggered by the watchdog service 20 when a failure in the operating system is detected.

[0185] The embodiment of the present application proposes a deadlock fault analysis method. The computing device can run a watchdog service. When a failure of the operating system is detected, the computing device can obtain lock information through a callback function and save the lock information to a log file; or the computing device can query a memory image file to obtain lock information and display the lock information. The lock information includes: data structure information of the lock, the application order of at least one CPU applying for the lock, and call stack information corresponding to at least one CPU.

[0186] The following is a detailed description of the deadlock fault analysis method of the embodiment of the present application. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0187] Figure 2a This is a flow chart of a first embodiment of a deadlock fault analysis method provided in an embodiment of the present application. Figure 2a , the method specifically comprises the following steps:

[0188] S201: Running the watchdog service, and when detecting that the operating system fails, calling the callback function to obtain lock information.

[0189] Figure 2b Schematic diagram 1 of a scenario for obtaining lock information provided in an embodiment of the present application.

[0190] In this embodiment, an operating system runs on the computing device.

[0191] like Figure 1bAs shown, the watchdog service and lock information analysis program are both located in kernel mode.

[0192] During the operating system startup phase, the lock information analysis program can be started as a boot service. In one implementation, the lock information analysis program is a service managed by systemd (the first program started by the kernel). During the systemd initialization phase of the operating system startup phase, systemd sends a startup command to the lock information analysis program. The lock information analysis program can be started in response to the startup command.

[0193] After the lock information analysis program is started, the lock information analysis program can be registered as a callback function in the notification chain of the watchdog service. It can be understood that the function pointer of the lock analysis program is added to the notification chain of the watchdog service.

[0194] The computing device may run a watchdog service, and when a failure of the operating system is detected, the watchdog service may call a lock information analysis program (callback function) registered on the notification chain to enable the lock information analysis program (callback function) to obtain lock information.

[0195] It should be noted that the lock information refers to the information of the lock of the computing device. In one implementation, the lock may be a spin lock.

[0196] The lock information includes: data structure information of the lock, an application order of at least one central processing unit (CPU) for using the lock, and call stack information corresponding to at least one CPU.

[0197] In one implementation, the computing device may run a watchdog service, and when a failure of the operating system is detected, the computing device may call a callback function to obtain the lock information. In other words, the computing device may run the callback function to directly obtain the lock information.

[0198] In one implementation, the computing device may run a watchdog service, and when a failure of the operating system is detected, the computing device may obtain the lock information through a callback function when it is determined that the lock information acquisition condition is met. In other words, the computing device may run a callback function, and when it is determined that the lock information acquisition condition is met, the computing device may obtain the lock information.

[0199] Next, the process of executing the callback function on the computing device and obtaining the lock information when it is determined that the conditions for obtaining the lock information are met is described.

[0200] In one implementation:

[0201] The computing device can run the callback function to obtain the call stack information corresponding to the target CPU. The call stack information corresponding to the target CPU includes the call information of at least one function; the target CPU is the CPU running when the operating system fails. In other words, the call stack information corresponding to the target CPU is the call stack information corresponding to the CPU running when the operating system fails. It should be noted that the call stack information corresponding to the running CPU refers to the call stack information of the process corresponding to the running CPU.

[0202] The computing device may run the callback function to determine whether there is call information of a target function in the call information of at least one function, wherein the target function is a call function for acquiring a lock. Exemplarily, the call function may be native_queued_spin_lock_slowpath.

[0203] The computing device may run the callback function, and when it is determined that the calling information of at least one function contains the calling information of the target function, determine that the acquisition condition of the lock information is satisfied, that is, determine that the operating system failure is caused by the lock.

[0204] The computing device may run the callback function, and terminate the process when it is determined that the call information of the target function does not exist in the call information of at least one function. That is, the watchdog service may continue to call other callback functions registered to the call notification chain.

[0205] By setting the lock information acquisition conditions in the above manner, the utilization rate of the lock information can be improved.

[0206] Next, the process of executing the callback function on the computing device and obtaining the lock information is described.

[0207] In one implementation:

[0208] The computing device may run the callback function and read the target register to obtain the lock address. For example, when the processor architecture is the x86_64 architecture, the target register may be the R0 register; when the processor architecture is the arm64 architecture, the target register may be the x3 register. It should be noted that, in one implementation, the computing device may run the callback function, determine the target register according to the identifier of the target register obtained in advance, and read the target register to obtain the lock address.

[0209] The computing device may run the callback function to obtain the data structure information of the lock according to the lock address. In one implementation, the lock address is a virtual address, and the computing device may run the callback function to determine the physical address according to the lock address. The computing device may run the callback function to obtain the data structure information of the lock according to the physical address.

[0210] The computing device may run the callback function to determine the application order according to the data structure information of the lock, wherein the application order includes the identification of at least one CPU.

[0211] The computing device may run a callback function to obtain call stack information corresponding to at least one CPU according to the application order. In one implementation, for an identifier of any CPU in the application order, the computing device may run a callback function to obtain call stack information corresponding to the CPU according to the identifier of the CPU. It should be noted that the call stack information corresponding to the CPU refers to the call stack information of the process corresponding to the CPU.

[0212] Next, the process of executing the callback function on the computing device and obtaining the call stack information corresponding to at least one CPU according to the application order is described.

[0213] In one implementation,

[0214] The computing device runs the callback function, which can trigger the kernel to broadcast an interrupt to the CPU corresponding to each CPU identifier in the application order. After receiving the interrupt, the CPU can call the interrupt callback function to print the call stack information corresponding to the CPU (store the call stack information in the kernel buffer). In one implementation, the interrupt can be a non-maskable interrupt (NMI). In one implementation, the interrupt can be an inter-processor interrupt (IPI).

[0215] Next, the process of running the callback function on the computing device and determining the application order according to the data structure information of the lock is described.

[0216] In one implementation:

[0217] Figure 2c A schematic diagram of data structure information of a lock provided in an embodiment of the present application.

[0218] like Figure 2c As shown, the lock data structure information records the following information:

[0219] Lock state: It should be noted that the lock state indicates whether the lock is occupied. In one implementation, the lock state is 0, indicating that the lock is not occupied; the lock state is 1, indicating that the lock is occupied;

[0220] Waiting for occupancy status (pengding bit status); It should be noted that the waiting for occupancy status indicates whether there is a CPU that has applied for use and does not occupy the lock. In one implementation, the waiting for occupancy status is 0, indicating that there is no CPU that has applied for use and does not occupy the lock; the waiting for occupancy status is 1, indicating that there is a CPU that has applied for use and does not occupy the lock;

[0221] Lock index: It should be noted that the lock index is used to indicate the data structure (struct qnode) related to the lock in the qnodes data structure corresponding to the first CPU. Exemplarily, the lock index is 0, indicating that in the qnodes data structure corresponding to the first CPU, the data structure (struct qnode) related to the lock is the first data structure among multiple data structures; the lock index is 1, indicating that in the qnodes data structure corresponding to the first CPU, the data structure (struct qnode) related to the lock is the second data structure among multiple data structures;

[0222] Identification of the first CPU. Exemplarily, the identification of the first CPU may be the serial number of the first CPU. It should be noted that the first CPU is the last CPU to apply for the lock.

[0223] Based on the fact that the identification of the first CPU is recorded in the data structure information of the lock, the computing device can run the callback function to determine the first CPU in the data structure information.

[0224] The computing device may execute the callback function to determine whether the first CPU holds the lock.

[0225] In one implementation, the computing device may run a callback function to determine the waiting for possession state in the data structure information. The computing device may run the callback function to determine whether the waiting for possession state indicates that there is no CPU that has applied for use and does not occupy the lock. If so, the computing device may run the callback function to determine that the first CPU occupies the lock; if not, the computing device may run the callback function to determine that the first CPU does not occupy the lock.

[0226] In one implementation, the data structure corresponding to the CPU records indication information, and the indication information is used to indicate whether the lock is occupied. The computing device can run a callback function to determine the qnodes data structure corresponding to the first CPU according to the identifier of the first CPU. The computing device can run a callback function to determine a data structure in the qnodes data structure according to the lock index. The computing device can run a callback function to determine whether the indication information recorded in the data structure indicates that the lock is occupied; if so, the computing device can run the callback function to determine that the first CPU occupies the lock; if not, the computing device can run the callback function to determine that the first CPU does not occupy the lock.

[0227] The computing device may execute the callback function, and when it is determined that the first CPU holds the lock, determine that the application order includes the identifier of the first CPU.

[0228] The computing device may run the callback function, and when it is determined that the first CPU does not occupy the lock, perform at least one CPU search operation, and determine the application order according to the first CPU and the CPU found.

[0229] Next, the process of running the callback function on the computing device, performing at least one CPU search operation, and determining the application order according to the first CPU and the CPU found is described.

[0230] In one implementation,

[0231] The computing device can run the callback function, and according to the address information of the data structure corresponding to the i-th CPU, search and process the data structures corresponding to all CPUs to obtain the i+1th CPU. It should be noted that the i+1th CPU is the CPU that applied for the lock before the i-th CPU. The data structure corresponding to the i+1th CPU includes the address information of the data structure corresponding to the i-th CPU.

[0232] The computing device may execute the callback function to determine whether the (i+1)th CPU holds the lock.

[0233] The computing device may run the callback function, and when it is determined that the (i+1)th CPU holds the lock, determine that the (i+1)th CPU applies for the lock before the (i)th CPU, and terminate the search operation.

[0234] The computing device may run the callback function, and when it is determined that the (i+1)th CPU does not occupy the lock, determine that the (i+1)th CPU applies for the lock before the (i)th CPU.

[0235] It should be noted that i is 1, 2, ... in sequence until the application order is obtained.

[0236] In addition, it should be noted that i is the inverse application (queue) number of a CPU in the application sequence.

[0237] When i is 1, the i-th CPU is the CPU with the first application number in the application sequence. In other words, the i-th CPU is the last CPU to apply for the lock - the first CPU.

[0238] Next, the search principle is explained.

[0239] Figure 2d A schematic diagram of the principle of a search operation provided in an embodiment of the present application.

[0240] like Figure 2d As shown, the qnodes data structure corresponding to the i+1th CPU includes multiple data structures (structqnode). The data structure includes address information and indication information of the data structure (structqnode) corresponding to the i-th CPU (the CPU that applies for the lock after the i+1th CPU).

[0241] The indication information is used to indicate whether the i+1th CPU occupies the lock. In one implementation, the indication information (lock value) is 0, indicating that the i+1th CPU does not occupy the lock; the indication information (lock value) is 1, indicating that the i+1th CPU occupies the lock.

[0242] The computing device may run a callback function, and search and process the data structures corresponding to all CPUs according to the address information of the data structure corresponding to the i-th CPU, to obtain the i+1th CPU. The data structure corresponding to the i+1th CPU includes the address information of the data structure corresponding to the i-th CPU. In one implementation, for any data structure corresponding to any CPU, the computing device may run a callback function, and search and process the data structure according to the address information of the data structure corresponding to the i-th CPU, to determine whether the data structure includes the address information of the data structure corresponding to the i-th CPU; if so, the CPU is determined to be the i+1th CPU, and the address information of the data structure is determined.

[0243] The computing device may run a callback function to determine whether the indication information recorded in the data structure corresponding to the i+1th CPU indicates that the lock is occupied. If so, the computing device may run a callback function to determine that the i+1th CPU occupies the lock; if not, the computing device may run a callback function to determine that the i+1th CPU does not occupy the lock.

[0244] In addition, it should be noted that in the process of searching for the previous CPU of the first CPU according to the address information of the data structure corresponding to the first CPU, the computing device can run a callback function to determine the qnodes data structure corresponding to the first CPU according to the identifier of the first CPU. The computing device can run a callback function to determine a data structure in the qnodes data structure according to the lock index. The computing device can run a callback function to determine the address information of the data structure as the address information of the data structure corresponding to the first CPU. The computing device can run a callback function to search for the previous CPU of the first CPU according to the address information of the data structure corresponding to the first CPU.

[0245] S202: Save the lock information to a log file, and analyze the deadlock fault according to the lock information in the log file.

[0246] In this embodiment, the computing device may save the lock information to a log file, so as to analyze the deadlock fault according to the lock information in the log file.

[0247] In one implementation, the computing device may run a callback function to save the lock information to a kernel buffer. The computing device may run an operating system to save the lock information in the kernel buffer to a log file (the log file is stored in a hard disk).

[0248] The computing device can analyze the deadlock failure based on the lock information in the log file.

[0249] In one implementation, the computing device may control a display interface of the computing device to display lock information.

[0250] Beneficial effects of this embodiment: In this embodiment, the computing device can run the watchdog service to monitor the operating system for faults, and call the callback function when the operating system is detected to have a fault, so that the callback function obtains the lock information. On the one hand, compared with the related art, the operation and maintenance engineer needs to manually use the analysis program to obtain the lock information based on the memory image file with a large amount of data, which may have the problem of low efficiency and accuracy. The method of the embodiment of the present application adopts the method of registering the callback function on the call chain of the watchdog service. In the case of a fault in the operating system, in response to the call of the watchdog service, the callback function can be run to obtain the lock information, thereby improving the efficiency and accuracy of obtaining the lock information. On the other hand, the callback function of the embodiment of the present application is to obtain the lock information based on the call of the watchdog service in the case of a fault in the operating system. The method of the embodiment of the present application does not need to obtain the lock information when the operating system does not have a fault, thereby reducing the resource overhead of the operating system and avoiding affecting the performance of the operating system. On the other hand, in the method of the embodiment of the present application, the callback function can be used as a separate module. When the callback function needs to be used to obtain the lock information, the callback function is registered on the notification chain of the watchdog service, thereby realizing the decoupling of the architecture and ensuring the portability of the callback function. On the other hand, compared with the related art, it is necessary to use the kernel crash dump service (kdump service) with poor reliability to generate a memory image file, and it is necessary to use an analysis program (such as a crash tool) to obtain and analyze the memory image file that may include sensitive information, resulting in poor security and poor reliability. The method of the embodiment of the present application can use the callback function registered to the notification chain of the watchdog service to automatically obtain lock information, thereby improving the efficiency and security of obtaining lock information.

[0251] Figure 3aThis is a flow chart of a second embodiment of a deadlock fault analysis method provided in an embodiment of the present application. Figure 3a , the method specifically comprises the following steps:

[0252] S301: Query the memory image file to obtain lock information.

[0253] In this embodiment, the computing device runs a kernel crash dump service (kdump service), and when an operating system failure is detected, the memory data at the time of the operating system failure can be saved and processed to obtain a memory image file (vmcore file).

[0254] The memory image file may include the identifier of the target CPU and the call stack information of all CPUs. It should be noted that the target CPU is the CPU that is running when the operating system fails.

[0255] The computing device can query the memory image file to obtain the lock information. In one implementation, the computing device can run the lock analysis plug-in to query the memory image file to obtain the lock information. It should be noted that in one implementation, Figure 3b A second schematic diagram of a scenario for obtaining lock information provided in an embodiment of the present application, Figure 3c The following is a schematic diagram of the interaction between the analysis program and the lock analysis plug-in. Figure 3b and Figure 3c As shown, the computing device can load the lock analysis plug-in by analyzing the program when obtaining the extension command. In one implementation, Figure 3d A schematic diagram of the built-in commands for the analysis program, such as Figure 3d As shown, when the computing device loads the lock analysis plug-in through the analysis program, the analysis command (such as the lock command) corresponding to the lock analysis plug-in can be registered in the built-in command of the analysis program. When the computing device runs the analysis program, it can call the lock analysis plug-in when obtaining the analysis command, so as to query the memory image file through the lock analysis plug-in and obtain the lock information.

[0256] In one implementation,

[0257] The computing device can obtain the call stack information corresponding to the target CPU. The call stack information corresponding to the target CPU includes the call information of at least one function. It should be noted that, in one implementation, the identification of the target CPU is stored in the memory image file, and the call stack information corresponding to all CPUs is stored. The computing device can query the memory image file, determine the target CPU, and query the memory image file to obtain the call stack information corresponding to the target CPU.

[0258] The computing device may query the memory image file to obtain the lock information when determining that the call information of the at least one function contains the call information of the target function, wherein the target function is the call function used to obtain the lock.

[0259] Next, the process of a computing device querying a memory image file and obtaining lock information is described.

[0260] In one implementation,

[0261] The computing device can query the memory image file to determine the target register in the target CPU. The target CPU is the CPU that is running when the operating system fails. The target register is the register that stores the lock address.

[0262] The computing device can read the target register to obtain the lock address.

[0263] The computing device can obtain the data structure information of the lock according to the lock address.

[0264] The computing device can determine the application order based on the data structure information of the lock.

[0265] The memory image file includes call stack information of multiple CPUs. The computing device can query the memory image file according to the application order to obtain the call stack information corresponding to at least one CPU.

[0266] Next, the process of determining the application order according to the data structure information of the lock by the computing device is described.

[0267] In one implementation,

[0268] The computing device may determine the first CPU in the data structure information; the first CPU is the last CPU to apply for the lock.

[0269] The computing device may determine whether the first CPU owns the lock.

[0270] If so, the computing device may determine that the application sequence includes an identification of the first CPU.

[0271] If not, the computing device may perform at least one CPU search operation, and determine the application order according to the first CPU and the CPU obtained by the search operation.

[0272] Next, a process of performing at least one search operation on a computing device is described.

[0273] In one implementation,

[0274] The computing device can search and process the data structures corresponding to all CPUs according to the address information of the data structure corresponding to the i-th CPU to obtain the i+1-th CPU. The i+1-th CPU is the CPU that applied for the lock before the i-th CPU; the data structure corresponding to the i+1-th CPU includes the address information of the data structure corresponding to the i-th CPU;

[0275] The computing device may determine whether the i+1th CPU holds the lock;

[0276] If so, the computing device may determine that the order in which the i+1th CPU applies to use the lock is before the i-th CPU, and terminate the search operation.

[0277] If not, the computing device may determine that the order in which the (i+1)th CPU applies to use the lock is before the (i)th CPU.

[0278] It should be noted that i is 1, 2, ... in sequence until the application order is obtained.

[0279] S302: Display lock information to analyze the deadlock fault according to the lock information.

[0280] In this embodiment, the computing device may display the lock information after obtaining the lock information, so as to analyze the deadlock fault according to the lock information.

[0281] That is, the computing device may control the display interface of the computing device to display the lock information.

[0282] Beneficial effects of this embodiment: In this embodiment, the computing device can obtain lock information by querying the memory image file. On the one hand, compared with the related art, which requires operation and maintenance engineers to manually use analysis programs and multiple commands to obtain lock information based on a memory image file with a large amount of data, which may have problems of low efficiency and accuracy, the method of the embodiment of the present application can directly and automatically query the memory image file to obtain lock information, thereby improving the efficiency, accuracy, and security of determining the lock information.

[0283] Next, a process of analyzing a deadlock failure by a computing device according to lock information is described through method embodiment 3.

[0284] In this embodiment, the computing device may analyze the deadlock fault according to the lock information.

[0285] It should be noted that, in one implementation, the computing device may run a callback function (such as a fault analysis module in the callback function) to analyze the deadlock fault according to the lock information. In one implementation, the computing device may run a lock analysis plug-in (such as a fault analysis module in the lock analysis plug-in) to analyze the deadlock fault according to the lock information.

[0286] In one implementation:

[0287] The data structure information of the lock includes the lock state and the waiting state. In addition, the data result information of the lock may also include the lock index and the identification of the first CPU.

[0288] The computing device may determine that a deadlock fault exists when the lock state indicates that the lock is occupied and the waiting-for-occupancy state indicates that there is a CPU that has applied for use but does not occupy the lock.

[0289] In one implementation:

[0290] The computing device may determine the second CPU according to the application order. The second CPU is the first CPU to apply for the lock. It should be noted that the CPU based on the first application for the lock is the CPU that occupies the lock, so the second CPU is the CPU that occupies the lock.

[0291] The computing device may determine the process corresponding to the second CPU based on the second CPU. It should be noted that the process corresponding to the second CPU is the process run by the second CPU when the operating system of the computing device fails.

[0292] The computing device may determine that the process corresponding to the second CPU has an abnormality. In addition, in one implementation, the computing device may perform recovery processing by terminating the process when determining that the process corresponding to the second CPU has an abnormality. In one implementation, the computing device may perform recovery processing by reinitializing the lock when determining that the process corresponding to the second CPU has an abnormality.

[0293] In one implementation:

[0294] The computing device can determine the call stack information corresponding to the second CPU based on the call stack information corresponding to the at least one CPU. The second CPU is the first CPU that applies to use the lock. It should be noted that the CPU that first applies to use the lock is the CPU that occupies the lock, so the second CPU is the CPU that occupies the lock.

[0295] The computing device may determine the function call relationship of the process corresponding to the second CPU according to the call stack information corresponding to the second CPU.

[0296] The computing device can determine that the function call relationship of the process corresponding to the second CPU has an anomaly.

[0297] Next, a process of determining, by the computing device, the function call relationship of the process corresponding to the second CPU based on the call stack information corresponding to the second CPU is described.

[0298] When the CPU runs a process, it can maintain a call stack corresponding to the process (the call stack is a data structure). The call stack uses stack frames (the basic unit of the call stack) to store the call information of functions. One stack frame stores the call information of one function. All the information stored in the call stack is the call stack information, that is, the call stack information includes the call information of at least one function.

[0299] Taking the first function as an example, when the first function in the process is called, the CPU can create a stack frame corresponding to the first function, and record the call information of the first function in the stack frame corresponding to the first function. The call information includes the function name, function parameters, return address (the location where the function is called), and local variables. When the first function calls the second function, the CPU can create a stack frame corresponding to the second function, and record the call information of the second function in the stack frame corresponding to the second function.

[0300] The computing device can determine the function call relationship based on the call stack information. In one implementation, the call stack is composed of multiple stack frames stacked in sequence. The stack frame at the top of the stack corresponds to the function currently being executed, and the stack frame below corresponds to the function that calls the function. The computing device can determine the function call relationship of the process by traversing the stack frames of the call stack.

[0301] In one implementation:

[0302] The computing device may determine the function call relationship of the process corresponding to the at least one CPU according to the call stack information corresponding to the at least one CPU.

[0303] The computing device can determine that there is an anomaly in the function call relationship of the process corresponding to at least one CPU.

[0304] Beneficial effects of this embodiment: After obtaining the lock information, the computing device can analyze the deadlock fault according to the lock information, and obtain a variety of information for determining the cause of the operating system failure. Compared with the related art, the operation and maintenance engineer needs to manually use the analysis program to obtain the lock information based on the memory image file with a large amount of data, and then analyze the deadlock fault based on the lock information and the memory image file with a large amount of data and the lock information, which may have problems of low efficiency and accuracy. The method of the embodiment of the present application can automatically analyze the deadlock fault based on the lock information, thereby improving the analysis efficiency and accuracy.

[0305] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0306] Figure 4A schematic diagram of the structure of a deadlock fault analysis device provided in an embodiment of the present application. Figure 4 As shown, the deadlock fault analysis device 70 includes a watchdog service 20 and a callback function (lock information analysis program) 30.

[0307] The watchdog service 20 is used to call the callback function to obtain lock information when a failure of the operating system is detected; the lock information includes: data structure information of the lock, the application order of at least one central processing unit CPU to apply for the use of the lock, and call stack information corresponding to at least one CPU;

[0308] The callback function 30 is used to save the lock information to a log file, so as to analyze the deadlock fault according to the lock information in the log file.

[0309] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0310] In one implementation, the callback function 30 includes:

[0311] The lock data structure analysis module 31 is used to read the target register and obtain the lock address; the target register is the register storing the lock address;

[0312] The lock data structure analysis module 31 is used to obtain the lock data structure information according to the lock address;

[0313] The lock queue analysis module 32 is used to determine the application order according to the data structure information of the lock;

[0314] The waiting-lock CPU call stack recording module 33 is used to obtain the call stack information corresponding to at least one CPU according to the application order.

[0315] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0316] In one implementation, the method further includes:

[0317] The scenario analysis module 34 is used to obtain the call stack information corresponding to the target CPU; wherein the call stack information corresponding to the target CPU includes the call information of at least one function; the target CPU is the CPU running when the operating system fails;

[0318] The scenario analysis module 34 is further used to determine that the calling information of at least one function contains calling information of a target function; the target function is a calling function used to acquire a lock.

[0319] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0320] In one implementation, the lock queue analysis module 32 is specifically configured to:

[0321] In the data structure information, the first CPU is determined; the first CPU is the last CPU to apply for the lock;

[0322] Determine whether the first CPU holds the lock;

[0323] If so, determining the application order includes only the identification of the first CPU;

[0324] If not, at least one CPU search operation is performed, and the application order is determined according to the first CPU and the CPU obtained by the search operation.

[0325] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0326] In one implementation, the lock queue analysis module 32 is specifically configured to:

[0327] According to the address information of the data structure corresponding to the i-th CPU, the i+1-th CPU is obtained; the i+1-th CPU is the CPU that applied for the lock before the i-th CPU; the data structure corresponding to the i+1-th CPU includes the address information of the data structure corresponding to the i-th CPU;

[0328] Determine whether the i+1th CPU holds the lock;

[0329] If yes, it is determined that the order in which the i+1th CPU applies for the lock is before the ith CPU, and the CPU search operation is terminated;

[0330] If not, it is determined that the order in which the i+1th CPU applies for the lock is before the i-th CPU.

[0331] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0332] In one implementation, the data structure information of the lock includes a lock state and a waiting state; the callback function also includes:

[0333] The fault analysis module 35 is used to determine that a deadlock fault exists when the lock state indicates that the lock is occupied and the waiting state indicates that there is a CPU that has applied for use but does not occupy the lock.

[0334] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0335] In one implementation, the fault analysis module 35 is further configured to:

[0336] Determine the second CPU according to the application order, and determine the process corresponding to the second CPU according to the second CPU, and determine that the process corresponding to the second CPU has an abnormality, and the second CPU is the first CPU to apply for the lock; or,

[0337] Determine call stack information corresponding to a second CPU based on call stack information corresponding to at least one CPU, determine function call relationships of a process corresponding to the second CPU based on the call stack information corresponding to the second CPU, and determine that there is an abnormality in the function call relationship of the process corresponding to the second CPU; or

[0338] According to the call stack information corresponding to the at least one CPU, a function call relationship of a process corresponding to the at least one CPU is determined, and it is determined that an abnormality exists in the function call relationship of the process corresponding to the at least one CPU.

[0339] The deadlock fault analysis device provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0340] Figure 5 A schematic diagram of the structure of the lock analysis plug-in provided in an embodiment of the present application.

[0341] like Figure 5 As shown, the lock analysis plug-in 60 is used to:

[0342] Query the memory image file to obtain lock information; the memory image file is a kernel crash dump service, and when the operating system fails, the memory data at the time of the operating system failure is saved and processed; the lock information includes: lock data structure information, the application order of at least one central processing unit CPU to apply for the use of the lock, and the call stack information corresponding to at least one CPU;

[0343] Display lock information to analyze deadlock faults based on the lock information.

[0344] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0345] In one implementation, the lock analysis plug-in 60 includes:

[0346] The lock data structure analysis module 61 is used to query the memory image file and determine the target register in the target CPU; the target CPU is the CPU that runs when the operating system fails; the target register is the register that stores the lock address;

[0347] The lock data structure analysis module 61 is used to read the target register and obtain the lock address;

[0348] The lock data structure analysis module 61 is used to obtain the lock data structure information according to the lock address;

[0349] The lock queue analysis module 62 is used to determine the application order according to the data structure information of the lock;

[0350] The waiting-lock CPU call stack recording module 63 is used to query the memory image file according to the application order and obtain the call stack information corresponding to at least one CPU.

[0351] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0352] In one implementation, the method further includes:

[0353] The scenario analysis module 64 is used to obtain call stack information corresponding to the target CPU; wherein the call stack information corresponding to the target CPU includes call information of at least one function; the target CPU is the CPU running when the operating system fails;

[0354] The scenario analysis module 64 is further used to determine that the calling information of at least one function contains calling information of a target function; the target function is a calling function used to acquire a lock.

[0355] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0356] In one implementation, the lock queue analysis module 62 is specifically configured to:

[0357] In the data structure information, the first CPU is determined; the first CPU is the last CPU to apply for the lock;

[0358] Determine whether the first CPU holds the lock;

[0359] If so, determining the application order includes only the identification of the first CPU;

[0360] If not, at least one CPU search operation is performed, and the application order is determined according to the first CPU and the CPU obtained by the search operation.

[0361] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0362] In one implementation, the lock queue analysis module 62 is specifically configured to:

[0363] According to the address information of the data structure corresponding to the i-th CPU, the i+1-th CPU is obtained; the i+1-th CPU is the CPU that applied for the lock before the i-th CPU; the data structure corresponding to the i+1-th CPU includes the address information of the data structure corresponding to the i-th CPU;

[0364] Determine whether the i+1th CPU holds the lock;

[0365] If yes, it is determined that the order in which the i+1th CPU applies for the lock is before the ith CPU, and the CPU search operation is terminated;

[0366] If not, it is determined that the order in which the i+1th CPU applies for the lock is before the i-th CPU.

[0367] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0368] In one implementation, the data structure information of the lock includes a lock state and a waiting state; the lock analysis plug-in further includes:

[0369] The fault analysis module 65 is used to determine that a deadlock fault exists when the lock state indicates that the lock is occupied and the waiting state indicates that there is a CPU that has applied for use but does not occupy the lock.

[0370] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0371] In one implementation, the fault analysis module 65 is further configured to:

[0372] Determine the second CPU according to the application order, and determine the process corresponding to the second CPU according to the second CPU, and determine that the process corresponding to the second CPU has an abnormality, and the second CPU is the first CPU to apply for the lock; or,

[0373] Determine call stack information corresponding to a second CPU based on call stack information corresponding to at least one CPU, determine function call relationships of a process corresponding to the second CPU based on the call stack information corresponding to the second CPU, and determine that there is an abnormality in the function call relationship of the process corresponding to the second CPU; or

[0374] According to the call stack information corresponding to the at least one CPU, a function call relationship of a process corresponding to the at least one CPU is determined, and it is determined that an abnormality exists in the function call relationship of the process corresponding to the at least one CPU.

[0375] The lock analysis plug-in provided in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0376] Figure 6 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. Figure 6 As shown, the computing device 80 includes: a processor 81 and a memory 82; wherein the processor 81 is coupled to the memory 82, and the memory 82 is used to store computer instructions; the processor 81 is used to execute computer instructions to enable the computing device 80 to execute the technical solution in the aforementioned method embodiment.

[0377] Optionally, the memory 82 may be independent or integrated with the processor 81. Optionally, when the memory 82 is a device independent of the processor 81, the first computing device 80 may further include: a bus 83 for connecting the above devices.

[0378] The processor is used to execute the technical solution in the aforementioned method embodiment, and its implementation principle and technical effect are similar and will not be repeated here.

[0379] An embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the technical solution provided by the aforementioned method embodiment.

[0380] An embodiment of the present application provides a computer program product, including a computer program, which is used to implement the technical solution provided by the aforementioned method embodiment when executed by a processor.

[0381] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: volatile memory, non-volatile memory and other media that can store program codes.

[0382] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A deadlock fault analysis method, characterized in that: include: Run the watchdog service, and when it detects an operating system failure, call the callback function to obtain the lock information; The lock information includes: data structure information of the lock, an application order of at least one central processing unit (CPU) for using the lock, and call stack information corresponding to at least one CPU; The lock information is saved in a log file, so as to analyze the deadlock fault according to the lock information in the log file.

2. The method according to claim 1, characterized in that: The acquiring of the lock information comprises: Reading a target register to obtain a lock address; the target register is a register storing the lock address; According to the lock address, obtaining data structure information of the lock; Determining the application order according to the data structure information of the lock; According to the application order, call stack information corresponding to the at least one CPU is obtained.

3. A deadlock fault analysis method, characterized in that: include: Query the memory image file to obtain lock information; The memory image file is a kernel crash dump service, which is obtained by saving and processing the memory data when the operating system fails when the operating system fails; the lock information includes: data structure information of the lock, the application order of at least one central processing unit CPU to apply for the use of the lock, and call stack information corresponding to at least one CPU; The lock information is displayed to analyze a deadlock fault according to the lock information.

4. The method according to claim 3, characterized in that The querying of the memory image file to obtain lock information includes: Query the memory image file to determine a target register in a target CPU; the target CPU is a CPU that runs when the operating system fails; the target register is a register that stores the lock address; Read the target register to obtain the lock address; According to the lock address, obtaining data structure information of the lock; Determining the application order according to the data structure information of the lock; According to the application order, the memory image file is queried to obtain call stack information corresponding to the at least one CPU.

5. The method according to any one of claims 1 to 4, characterized in that: Before acquiring the lock information, the method further includes: Acquire call stack information corresponding to the target CPU; wherein the call stack information corresponding to the target CPU includes call information of at least one function; the target CPU is the CPU running when the operating system fails; It is determined that the calling information of the at least one function includes calling information of a target function; the target function is a calling function used to acquire a lock.

6. The method according to claims 1-5, characterized in that: Determining the application order according to the data structure information of the lock includes: In the data structure information, a first CPU is determined; the first CPU is the last CPU to apply for using the lock; Determining whether the first CPU occupies the lock; If yes, determining that the application order only includes the identifier of the first CPU; If not, at least one CPU search operation is performed, and the application order is determined according to the first CPU and the CPU obtained by the search operation.

7. The method according to claim 6, characterized in that The performing at least one CPU search operation comprises: According to the address information of the data structure corresponding to the i-th CPU, the i+1-th CPU is obtained; the i+1-th CPU is the CPU that applied for the lock before the i-th CPU; the data structure corresponding to the i+1-th CPU includes the address information of the data structure corresponding to the i-th CPU; Determine whether the (i+1)th CPU occupies the lock; If yes, it is determined that the order in which the i+1th CPU applies to use the lock is before the ith CPU, and the CPU search operation is terminated; If not, it is determined that the order in which the i+1th CPU applies to use the lock is before the i-th CPU.

8. The method according to any one of claims 1 to 7, characterized in that: The data structure information of the lock includes a lock state and a waiting state; the method further includes: When the lock state indicates that the lock is occupied, and the waiting-for-occupancy state indicates that there is a CPU that has applied for use but does not occupy the lock, it is determined that a deadlock fault exists.

9. The method according to any one of claims 1 to 8, characterized in that: The method further comprises: Determine a second CPU according to the application order, and determine a process corresponding to the second CPU according to the second CPU, and determine that an abnormality exists in the process corresponding to the second CPU, and the second CPU is the first CPU to apply for the lock; or Determine the call stack information corresponding to the second CPU based on the call stack information corresponding to the at least one CPU, and determine the function call relationship of the process corresponding to the second CPU based on the call stack information corresponding to the second CPU, and determine that the function call relationship of the process corresponding to the second CPU is abnormal; or, According to the call stack information corresponding to the at least one CPU, a function call relationship of a process corresponding to the at least one CPU is determined, and it is determined that an abnormality exists in the function call relationship of the process corresponding to the at least one CPU.

10. A computing device, characterized in that include: A processor, and a memory communicatively connected to the processor; The memory is used to store computer-executable instructions; The processor is used to execute the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 9.

Images