A method for analyzing kernel soft deadlock, a processor, and a computing device.

Abstract

This application provides a method, processor, and computing device for analyzing kernel soft deadlocks, relating to the field of computer technology, and can improve the efficiency of users in handling kernel soft deadlocks. The method is applied to a processor (CPU) in a computing device. The method includes: when a kernel soft deadlock exists in the operating system (OS), obtaining thread information of a first thread; the first thread is the thread that triggered the kernel soft deadlock; if the thread information of the first thread includes a first lock identifier, the first lock identifier is used to indicate that the first thread is waiting to acquire a first target lock; generating a first analysis result of the kernel soft deadlock based on the lock information of the first target lock; the lock information of the first target lock includes an identifier of a second thread, and the first analysis result is used to indicate that the thread occupying the first target lock is the second thread; and outputting the first analysis result.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for analyzing kernel soft deadlock, a processor, and a computing device. Background Art

[0002] When a kernel soft deadlock occurs in the operating system (OS) of a computing device, the central processing unit (CPU) of the computing device will output an alarm message. This alarm message is used to instruct thread A to trigger a kernel soft deadlock in the OS.

[0003] However, the above warning information only indicates that thread A triggered a kernel soft deadlock in the OS, without indicating the reason why thread A triggered the kernel soft deadlock. This prevents users from quickly locating the vulnerability or bug that caused the kernel soft deadlock, and further reduces the efficiency of users in handling the kernel soft deadlock. Summary of the Invention

[0004] This application provides a method, processor, and computing device for analyzing kernel soft deadlocks, which can improve the user's efficiency in handling kernel soft deadlocks.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a method for analyzing kernel soft deadlock. This method is applied to a processor (CPU) in a computing device. The method includes: when a kernel soft deadlock exists in an operating system (OS), obtaining thread information of a first thread; the first thread is the thread that triggered the kernel soft deadlock; if the thread information of the first thread includes a first lock identifier, the first lock identifier is used to indicate that the first thread is waiting to acquire a first target lock; generating a first analysis result of the kernel soft deadlock based on the lock information of the first target lock; the lock information of the first target lock includes an identifier of a second thread, and the first analysis result is used to indicate that the thread occupying the first target lock is the second thread; and outputting the first analysis result.

[0007] This application provides a method for analyzing kernel soft deadlock. The method includes, when a kernel soft deadlock exists in the OS, obtaining thread information of the first thread that triggered the kernel soft deadlock. If the thread information includes a first lock identifier, generating a first analysis result of the kernel soft deadlock based on the lock information of the first target lock. This allows the user to determine, based on the first analysis result, that the cause of the kernel soft deadlock is that the first target lock that the first thread is waiting to acquire is held by a second thread for an extended period. This allows the user to quickly pinpoint the location of the bug causing the kernel soft deadlock (i.e., the second thread), further improving the user's efficiency in handling the kernel soft deadlock.

[0008] In one possible implementation, the first analysis result is further used to indicate that the second thread occupies the first target lock for a first duration; the first lock information includes the first duration; and / or; the first analysis result is further used to indicate the lock type of the first target lock, the first lock information includes the lock type of the first target lock, the lock type includes spin lock and read-write lock.

[0009] Since the first analysis result includes a first duration and the lock type of the first target lock, wherein the first duration is used to indicate the duration for which the second thread occupies the first target lock, and the lock type of the first target lock includes spin locks and read-write locks, users can more accurately locate the bug that causes the kernel soft deadlock, thereby improving the user's efficiency in handling the kernel soft deadlock.

[0010] In one possible implementation, the method further includes: generating a second analysis result when the first lock identifier is not present in the thread information of the first thread, the second analysis result being used to indicate that there is a delay fault in the first thread, the delay fault including at least: infinite loop and infinite recursion; and outputting the second analysis result.

[0011] In the above embodiment, when the first thread does not contain a first lock identifier in its thread information and the first thread is the thread that triggers the OS to cause a kernel soft deadlock, the CPU generates a second analysis result. This second analysis result is used to indicate that there is a delay fault in the first thread (specifically, an infinite loop and / or dead recursion). Then, the CPU outputs the second analysis result so that the user can know from the output of the second analysis result that the cause of the above kernel soft deadlock is the existence of an infinite loop and dead recursion in the first thread, thereby improving the user's processing efficiency for the kernel soft deadlock.

[0012] In one possible implementation, the method further includes: obtaining the thread information of the second thread; if the thread information of the second thread includes a second lock identifier, the second lock identifier is used to indicate that the second thread is waiting to acquire a second target lock; generating a third analysis result of the kernel soft deadlock based on the lock information of the second target lock; the third analysis result is used to indicate that the thread occupying the second target lock is a third thread; the lock information of the second target lock includes the identifier of the third thread; and outputting the third analysis result.

[0013] In the above embodiment, after the CPU outputs an indication that the first target lock awaited by the first thread is being held by the second thread for an extended period, the CPU acquires the thread information of the second thread. If the second thread's thread information contains a second lock identifier, the CPU generates and outputs a result indicating that the reason for the second thread's prolonged holding of the first target lock is that the second target lock awaited by the second thread is being held by the third thread for an extended period (i.e., the third analysis result). Here, the lock identifier of the second target lock is the second lock identifier, and the lock information of the second target lock includes the identifier of the third thread. If the second thread's thread information does not contain a second lock identifier, the CPU generates and outputs a result indicating that the reason for the second thread's prolonged holding of the first target lock is a delay fault in the second thread (i.e., the fourth analysis result). This allows the user to understand the reason for the second thread's prolonged holding of the first target lock based on the output of the third or fourth analysis result, thereby enabling the user to quickly locate the bug causing the kernel soft deadlock and further improving the user's efficiency in handling the kernel soft deadlock.

[0014] In one possible implementation, obtaining the thread information of the first thread includes: obtaining the thread information of the first thread when the first soft deadlock identifier is different from the current soft deadlock identifier; wherein the first soft deadlock identifier is the identifier of the kernel soft deadlock that the CPU last detected from the OS; and the current soft deadlock identifier is the identifier of the kernel soft deadlock that the CPU currently detects from the OS.

[0015] In the above embodiments, when the first soft deadlock identifier and the current soft deadlock identifier are different, the CPU executes the kernel soft deadlock analysis method provided in this application embodiment. The first soft deadlock identifier is the identifier of the kernel soft deadlock previously detected by the CPU from the OS, and the current soft deadlock identifier is the identifier of the kernel soft deadlock currently detected by the CPU from the OS. That is, if the currently detected kernel soft deadlock (i.e., the second kernel soft deadlock) and the previously detected kernel soft deadlock (i.e., the first kernel soft deadlock) are not the same kernel soft deadlock, the CPU executes the kernel soft deadlock analysis method provided in this application embodiment. If the first kernel soft deadlock and the second kernel soft deadlock are the same kernel soft deadlock, the kernel soft deadlock analysis method provided in this application embodiment is not executed. This avoids the CPU analyzing and outputting the same kernel soft deadlock multiple times, thus saving CPU processing and output resources.

[0016] In one possible implementation, after outputting the first analysis result, the method further includes: updating the first soft deadlock identifier using the current soft deadlock identifier, so that the updated first soft deadlock identifier is the same as the current soft deadlock identifier.

[0017] In one possible implementation, the method further includes: persisting the first analysis result and the CPU call stack information to a hard disk in a computing device; the call stack information includes: the function identifier of the function called by the CPU, the execution time of the function by the CPU, and the call relationship between the functions called by the CPU.

[0018] The above embodiments persist the first analysis result and the call stack information of the CPU where the first thread is located to the hard disk, thus avoiding the loss of the first analysis result and the call stack information of the CPU due to abnormal restart of the computing device.

[0019] In one possible implementation, the method further includes: when the first thread is in a state of waiting to acquire the first target lock, adding the first lock identifier to the thread information of the first thread.

[0020] Secondly, this application provides an analysis device comprising: a transceiver unit and a processing unit; the transceiver unit is configured to acquire thread information of a first thread when a kernel soft deadlock exists in the operating system (OS); the first thread is the thread that triggered the kernel soft deadlock, and when the thread information includes a first lock identifier, the first lock identifier is used to indicate that the first thread is waiting to acquire a first target lock; the processing unit is configured to generate a first analysis result of the kernel soft deadlock based on the lock information of the first target lock; the lock information of the first target lock includes an identifier of a second thread, and the first analysis result is used to indicate that the thread occupying the first target lock is the second thread; the transceiver unit is also configured to output the first analysis result.

[0021] In one possible implementation, the first analysis result is further used to indicate that the second thread occupies the first target lock for a first duration; the first lock information includes: the first duration; and / or; the first analysis result is further used to indicate the lock type of the first target lock, the first lock information includes: the lock type of the first target lock, the lock type includes: spin lock and read-write lock.

[0022] In one possible implementation, the processing unit is further configured to generate a second analysis result if the first lock identifier is not present in the thread information. The second analysis result is used to indicate that there is a delay fault in the first thread, and the delay fault includes at least: infinite loop and infinite recursion. The transceiver unit is further configured to output the second analysis result.

[0023] In one possible implementation, the transceiver unit is further configured to acquire thread information of the second thread; if the thread information of the second thread includes a second lock identifier, the second lock identifier is used to indicate that the second thread is waiting to acquire the second target lock; the processing unit is further configured to generate a third analysis result of kernel soft deadlock based on the lock information of the second target lock; the third analysis result is used to indicate that the thread occupying the second target lock is the third thread; the lock information of the second target lock includes an identifier of the third thread; the transceiver unit is also configured to output the third analysis result.

[0024] In one possible implementation, the transceiver unit is used to obtain the thread information of the first thread when the first soft deadlock identifier is different from the current soft deadlock identifier; wherein, the first soft deadlock identifier is the identifier of the kernel soft deadlock that the CPU last detected from the OS; and the current soft deadlock identifier is the identifier of the kernel soft deadlock that the CPU currently detects from the OS.

[0025] In one possible implementation, the processing unit is used to update the first soft deadlock identifier using the current soft deadlock identifier, so that the updated first soft deadlock identifier is the same as the current soft deadlock identifier.

[0026] In one possible implementation, the analysis device further includes a storage unit for persisting the first analysis result and the CPU call stack information to a hard disk in a computing device; the call stack information includes: function identifiers of functions called by the CPU, the duration of CPU function execution, and the call relationships between functions called by the CPU.

[0027] In one possible implementation, the processing unit is used to add the first lock identifier to the thread information of the first thread when the first thread is in a state of waiting to acquire the first target lock.

[0028] Thirdly, a processor is provided that executes the methods of the first aspect and its possible implementations.

[0029] Fourthly, a computing device is provided, comprising a processor and a memory electrically connected to the processor; the memory is used to store program instructions, which the processor executes to implement the method of the first aspect and its possible implementations.

[0030] Fifthly, a computer-readable storage medium is provided, which stores computer instructions that, when executed by a computing device, cause the computing device to perform the functions of the means of the first aspect and its possible implementations.

[0031] In a sixth aspect, a computer program product containing instructions is provided, which, when run on a computing device, causes the computing device to perform the functions of the apparatus of the first aspect and its possible implementations described above.

[0032] It should be understood that the beneficial effects achieved by the second to sixth aspects of the technical solutions and the corresponding possible implementations of the embodiments of this application can be referred to the above-described technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application;

[0034] Figure 2 A flowchart illustrating a kernel soft deadlock analysis method provided in this application embodiment;

[0035] Figure 3 A flowchart illustrating another kernel soft deadlock analysis method provided in this application embodiment;

[0036] Figure 4 A flowchart illustrating another kernel soft deadlock analysis method provided in this application embodiment;

[0037] Figure 5 This is a schematic diagram of the structure of an analysis device provided in an embodiment of this application. Detailed Implementation

[0038] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0039] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first thread" and "second thread," etc., are used to distinguish different threads, not to describe a specific order of threads.

[0040] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0041] First, some concepts involved in the kernel soft deadlock analysis method, processor, and computing device provided in the embodiments of this application will be explained as follows:

[0042] Kernel: This is the software that provides applications with secure access to the hardware of the computing device where the OS resides.

[0043] Kernel soft deadlock: CPU resources are occupied by a process or thread for a long time and cannot be released, causing other processes or threads to be unable to use the CPU resources to run their tasks, resulting in task blocking.

[0044] A process is an instance of a running program, representing a single execution activity of a program with a certain independent function on a specific data set. It is the basic unit of dynamic execution in an operating system. In traditional operating systems, a process is both the basic unit of allocation and the basic unit of execution.

[0045] A thread is the smallest unit of computation that an operating system can schedule. It is contained within a process and is the actual unit of operation within that process. A thread refers to a single, sequential flow of control within a process. Multiple threads can run concurrently within a process, each executing different tasks in parallel.

[0046] Interrupt: Used to instruct a computing device to pause a running program and switch to a program that handles a new task. After the new task is completed, the program returns to the original paused program and continues running.

[0047] Based on the aforementioned background technology, this application provides a method for analyzing kernel soft deadlock. The method includes: when a kernel soft deadlock exists in the OS, obtaining thread information of the first thread that triggered the kernel soft deadlock; if the thread information includes a first lock identifier, the first lock identifier is used to indicate that the first thread is waiting to acquire a first target lock. Then, based on the lock information of the first target lock, generating a first analysis result of the kernel soft deadlock; the first analysis result indicates that the thread occupying the first target lock is a second thread; the lock information of the first target lock includes the identifier of the second thread; finally, outputting the first analysis result. This allows the user to know, based on the first analysis result, that the cause of the kernel soft deadlock is the long-term occupation of the first target lock by the second thread, thus enabling the user to quickly determine the location of the bug causing the kernel soft deadlock (i.e., the second thread), further improving the user's efficiency in handling the kernel soft deadlock.

[0048] It should be noted that the kernel soft deadlock analysis method provided in this application embodiment is applied to scenarios where kernel soft deadlock occurs in the OS of a computing device.

[0049] For example, the above-mentioned computing device, such as Figure 1 As shown, the computing device can be a blade server, a high-density server, a rack server, or a full-rack server in terms of form; in terms of processor architecture, the computing device can be an x86 server, an ARM server, or a graphics processing unit (GPU) server.

[0050] The hardware of this computing device includes a processor (exemplarily a CPU), a management controller, and memory. The software primarily includes a management control module, processor firmware (not shown in the figure), and an operating system (OS). The management control module runs within the management controller, the OS runs within the processor, and the processor firmware runs within the processor (e.g., ...). Figure 1 (As shown). The management and control module can be a management unit for non-business modules. This management and control module is completely independent of the operating system of the computing device and can communicate with the basic input / output system (BIOS) and the operating system.

[0051] It should be noted that the CPU in the above-mentioned computing device can be a multi-core CPU or a single-core CPU. For ease of description, this application embodiment uses a single-core CPU as an example for illustration, and will not be repeated hereafter.

[0052] The aforementioned processor firmware (also referred to as processor firmware program) can be firmware, basic input output system (BIOS), management engine (ME), microcode, or intelligent management unit (IMU), etc. It should be noted that the specific form of the processor firmware in this application embodiment is not limited; the above is merely illustrative. In the following embodiments, only the BIOS processor firmware is used as an example for explanation.

[0053] Memory, also known as internal memory or main memory, is installed in memory slots on the motherboard of a computing device. Memory communicates with the processor through memory channels.

[0054] The management controller can be, for example, a baseboard management controller (BMC), or of course, a controller with monitoring and management functions.

[0055] It should be noted that different computing devices use different names for BMC. For example, some computing devices call it BMC, some call it iLO (Integrated lights-out), and others call it Integrated Dell Remote Access Controller (iDRAC). Regardless of whether it is called BMC, iLO, or iDRAC, it can be understood as the BMC in the embodiments of this invention.

[0056] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0057] This application provides a kernel soft deadlock analysis method, which is applied to... Figure 1 The CPU in the computing device shown, such as Figure 2 As shown, the method includes S110-S140.

[0058] S110, CPU detects whether there is a kernel soft deadlock in the OS of the computing device.

[0059] In one implementation, each CPU in the computing device where the aforementioned CPU resides corresponds to a high-resolution timer (hrtimer), and each CPU has a watchdog / x thread. Based on this, the aforementioned S110 specifically includes: S1-S2.

[0060] S1 and hrtimer periodically trigger CPU interrupts and send wake-up commands to the watchdog thread in that CPU.

[0061] The specific implementation of the above-mentioned hrtimer triggering a CPU interrupt can be that the hrtimer sends an interrupt request to the CPU, and the CPU responds to the interrupt request and causes an interrupt; or the hrtimer sends an interrupt instruction to the CPU, thereby controlling the CPU to cause an interrupt. In this application, the specific implementation method of the hrtimer triggering a CPU interrupt is not specifically limited.

[0062] It should be noted that the above wake-up command is used to wake up the watchdog thread that is in a sleeping state. When the watchdog thread is successfully woken up and is in the awakened state, the watchdog thread will update the target timestamp to the current timestamp (referred to as: current timestamp). After that, the watchdog thread switches back to the sleeping state.

[0063] It should be understood that although the hrtimer sends a wake-up command to the watchdog thread, once the CPU exits the interrupt, it will continue to execute tasks that were not completed before the interrupt. That is, the thread that occupied the CPU resources before the interrupt (such as thread A) will continue to occupy those resources after the interrupt ends. If thread A experiences a soft deadlock, it will continue to occupy the CPU resources, preventing the watchdog thread from updating the target timestamp, thus causing the difference between the current timestamp and the target timestamp to increase.

[0064] S2. The CPU determines whether the difference between the current timer of the hrtimer and the target timestamp is greater than or equal to the threshold.

[0065] The current timer of the above hrtimer is the current timestamp.

[0066] When the difference between the current timer of hrtimer and the target timestamp (hereinafter referred to as the target difference) is less than the threshold, it means that the watchdog thread was successfully woken up within the predetermined time and updated the target timestamp; that is, the CPU resource is not occupied by a thread for a long time, so the CPU determines that there is no kernel soft deadlock in the OS.

[0067] When the difference between the current timer and the target timestamp (referred to as the target difference) is greater than or equal to the threshold, it means that the watchdog thread was not successfully woken up within the predetermined time. In other words, the CPU resource was occupied by a certain thread for a long time, so the CPU determined that there was a kernel soft deadlock in the OS.

[0068] It should be noted that the specific implementation of S110 above can be implemented in the manner described in S1-S2 above, or in other ways (for example, when a thread in the OS kernel occupies CPU resources for a duration longer than a preset duration, the CPU determines that there is a kernel soft deadlock in the OS). The specific implementation of S110 in this application does not limit the specific implementation of S110 above.

[0069] In the absence of a kernel soft deadlock in the aforementioned OS, the CPU executes a termination action, ending the current method flow.

[0070] In the case of a kernel soft deadlock in the above OS, the CPU executes the following S120.

[0071] S120, The CPU obtains the thread information of the first thread.

[0072] The CPU mentioned above includes at least one thread, and the first thread mentioned above is the thread that triggers the OS to cause a kernel soft deadlock.

[0073] It should be noted that when a kernel soft deadlock occurs in the OS, the CPU will output the identifier of the thread that triggered the kernel soft deadlock in the OS's system log; based on this, the CPU can determine the first thread that triggered the kernel soft deadlock according to the OS's system log.

[0074] The thread information of the first thread mentioned above includes: a first lock identifier; the first lock identifier is used to indicate the first target lock that the first thread is waiting to acquire; that is, the thread information of the first thread includes the lock identifier of the first target lock that the first thread is waiting to acquire (i.e., the first target lock); thus, it can be seen that when a thread is waiting to acquire a lock, the thread information of the thread includes the lock identifier of the lock that the thread is waiting to acquire.

[0075] It should be noted that the first lock identifier mentioned above can be added by the CPU to the thread information of the first thread when the first thread is in a state of waiting to acquire the first target lock; or it can be added by the CPU to the thread information of the first thread and the thread information of other threads when the first thread and other threads in the CPU compete for the first target lock.

[0076] After the first thread acquires the first target lock, the CPU removes the first lock identifier from the thread information of the first thread and adds the identifier of the first thread to the lock information of the first target lock indicated by the first lock identifier; that is, when a thread holds (i.e. acquires) the target lock, the lock information of the target lock includes the identifier of the thread.

[0077] Furthermore, when the first thread releases the first target lock, the CPU removes the identifier of the first thread from the lock information of the first target lock.

[0078] For example, suppose there are threads A, B, and C in the CPU. When threads A, B, and C simultaneously compete for a target lock, when thread C acquires the target lock, the CPU adds thread C's identifier to the lock information of the target lock. At this time, threads A and B are in a waiting state to acquire the target lock; that is, the CPU adds the target lock's identifier to the thread information of threads A and B respectively. When thread C releases the target lock, the CPU removes thread C's identifier from the target lock's lock information. At this time, threads A and B simultaneously compete for the target lock. When thread B acquires the target lock, the CPU removes the target lock's identifier from thread B's thread information and adds thread B's identifier to the target lock's lock information, and so on, until thread A releases the target lock.

[0079] S130. If the thread information of the first thread includes the first lock identifier, the CPU generates the first analysis result of the kernel soft deadlock based on the lock information of the first target lock.

[0080] It should be noted that the lock information of the first target lock mentioned above is obtained by the CPU from memory based on the first lock identifier.

[0081] The lock information of the first target lock mentioned above includes: the identifier of the second thread; the second thread is the thread currently holding (i.e., possessing) the first target lock.

[0082] It should be understood that when the second thread acquires the first target lock, the CPU will delete the first lock identifier from the thread information of the second thread and add the identifier of the second thread to the lock information of the first target lock to indicate that the first target lock is currently occupied by the second thread.

[0083] The first analysis result indicates that the thread holding the first target lock is the second thread. Since the first target lock that the first thread was waiting to acquire is held by the second thread, and the first thread is the thread that triggered the OS to cause a kernel soft deadlock, the user can know that the cause of the kernel soft deadlock is that the first target lock has been held by the second thread for a long time after obtaining the first analysis result.

[0084] In one implementation, the first analysis result above also includes: a first duration and / or the lock type of the first target lock.

[0085] The aforementioned first duration is used to indicate the duration for which the second thread occupies the aforementioned first target lock. For example, when the duration from when the second thread acquires the aforementioned first target lock to when the second thread releases the aforementioned first target lock is 30 seconds, the first duration is 30 seconds.

[0086] It should be noted that the lock information of the first target lock mentioned above also includes: a start timestamp, which is the timestamp when the second thread acquires the first target lock; if the second thread does not release the first target lock, the first duration mentioned above is the difference between the current timestamp and the start timestamp. In other words, the CPU can determine the first duration mentioned above based on the current timestamp and the start timestamp in the lock information of the first target lock.

[0087] For example, suppose the timestamp when the second thread acquires the first target lock is 1701685174 seconds; then, the CPU sets the start timestamp in the lock information of the first target lock to 1701685174 seconds; and suppose the current timestamp is 1701685204 seconds, then the CPU determines the difference between the current timestamp and the above start timestamp as the first duration, that is, the first duration is 30 seconds.

[0088] The lock information of the first target lock also includes: the lock type of the first target lock; the lock type includes at least: spin lock and read-write lock, wherein the lock type of the first target lock is added to the lock information of the first target lock by the CPU when the first target lock is initialized.

[0089] S140, CPU outputs the first analysis result.

[0090] It should be noted that the specific implementation of the above S140 may be that the CPU outputs the first analysis result in the kernel log of the OS, or the CPU outputs the first analysis result in the management interface of the OS. The specific implementation of this application does not limit the output location of the first analysis result.

[0091] Optionally, after the CPU executes the above S140, the method further includes: the CPU persisting the first analysis result and the call stack information of the CPU where the first thread is located to the hard disk in the above computing device.

[0092] The CPU call stack information mentioned above is used to quickly locate the specific location of the bug that caused the kernel soft deadlock, in conjunction with the first analysis results. The call stack information includes at least: the function identifiers of the functions called by the CPU, the execution time of each function by the CPU, and the call relationships between the functions called by the CPU.

[0093] The above embodiments persist the first analysis result and the call stack information of the CPU where the first thread is located to the hard disk, thus avoiding the loss of the first analysis result and the call stack information of the CPU due to abnormal restart of the computing device.

[0094] This application provides a method for analyzing kernel soft deadlocks. The method includes: when a kernel soft deadlock exists in the OS, obtaining thread information of the first thread that triggered the kernel soft deadlock; if the thread information includes a first lock identifier, the first lock identifier indicates that the first thread is waiting to acquire a first target lock. Then, based on the lock information of the first target lock, generating a first analysis result of the kernel soft deadlock; the first analysis result indicates that the thread holding the first target lock is a second thread; the lock information of the first target lock includes an identifier of the second thread; finally, outputting the first analysis result. This allows users to know from the first analysis result that the cause of the kernel soft deadlock is that the first target lock, which the first thread is waiting to acquire, is held by the second thread for a long time. This allows users to quickly determine the location of the bug causing the kernel soft deadlock (i.e., the second thread), further improving the efficiency of handling kernel soft deadlocks.

[0095] Furthermore, since the first analysis result includes a first duration and the lock type of the first target lock, wherein the first duration is used to indicate the duration for which the second thread occupies the first target lock, and the lock type of the first target lock includes spin locks and read-write locks, users can more accurately locate the bug that causes the kernel soft deadlock, thereby improving the user's efficiency in handling the kernel soft deadlock.

[0096] Based on the above Figure 2 The method for analyzing kernel soft deadlock shown in the previous embodiment provides another method for analyzing kernel soft deadlock, such as... Figure 3 As shown, the method includes: S210-S280.

[0097] S210, CPU detects whether there is a kernel soft deadlock in the OS of the computing device.

[0098] It should be noted that the implementation of S210 is the same as that of S110. For a detailed description of S210, please refer to the relevant description of S110 above. It will not be repeated here.

[0099] In the absence of a kernel soft deadlock in the aforementioned OS, the CPU executes a termination action, ending the current method flow.

[0100] In the case of a kernel soft deadlock in the above OS, the CPU executes the following S220.

[0101] S220, CPU acquires the first soft deadlock flag.

[0102] The aforementioned first soft deadlock identifier is the identifier of the kernel soft deadlock that the CPU last detected from the OS; that is, the first soft deadlock identifier is the identifier of the kernel soft deadlock (hereinafter referred to as: the first kernel soft deadlock) detected by the CPU last time it executed the aforementioned S210. Specifically, the first soft deadlock identifier can be the identifier of the thread that triggered the aforementioned first kernel soft deadlock.

[0103] It should be noted that the CPU in S220 above can obtain the first soft deadlock identifier from the memory of the computing device; it can also obtain the first soft deadlock identifier from other devices. In specific embodiments of this application, the storage location of the first soft deadlock identifier is not specifically limited.

[0104] S230, The CPU determines whether the first soft deadlock identifier is the same as the current soft deadlock identifier.

[0105] The aforementioned current soft deadlock identifier is the identifier of the kernel soft deadlock currently detected by the CPU from the OS; that is, the current soft deadlock identifier is the identifier of the kernel soft deadlock (referred to as: the second kernel soft deadlock) detected by the CPU during the execution of S210. Specifically, this current soft deadlock identifier is the identifier of the thread that triggered the aforementioned second kernel soft deadlock.

[0106] If the first soft deadlock identifier is the same as the current soft deadlock identifier, that is, if the first kernel soft deadlock and the second kernel soft deadlock are the same kernel soft deadlock, the CPU executes the termination action and ends the current method flow.

[0107] If the first soft deadlock identifier is different from the current soft deadlock identifier, that is, if the first kernel soft deadlock and the second kernel soft deadlock are different kernel soft deadlocks, the CPU executes the following S230.

[0108] It should be understood that when the first kernel soft deadlock and the second kernel soft deadlock are the same kernel soft deadlock, the CPU has already analyzed the cause of the first kernel soft deadlock and output the analysis results. Therefore, there is no need to repeat the analysis of the second kernel soft deadlock, and the CPU executes the termination action. When the first kernel soft deadlock and the second kernel soft deadlock are different kernel soft deadlocks, it means that the first kernel soft deadlock has been handled, and the second kernel soft deadlock is a newly emerging kernel soft deadlock. Therefore, the CPU needs to re-analyze the cause of the second kernel soft deadlock. Thus, the CPU executes the following S240.

[0109] In the above embodiments, when the first soft deadlock identifier and the current soft deadlock identifier are different, the CPU executes the kernel soft deadlock analysis method provided in this application embodiment. The first soft deadlock identifier is the identifier of the kernel soft deadlock previously detected by the CPU from the OS, and the current soft deadlock identifier is the identifier of the kernel soft deadlock currently detected by the CPU from the OS. That is, if the currently detected kernel soft deadlock (i.e., the second kernel soft deadlock) and the previously detected kernel soft deadlock (i.e., the first kernel soft deadlock) are not the same kernel soft deadlock, the CPU executes the kernel soft deadlock analysis method provided in this application embodiment. If the first kernel soft deadlock and the second kernel soft deadlock are the same kernel soft deadlock, the kernel soft deadlock analysis method provided in this application embodiment is not executed. This avoids the CPU analyzing and outputting the same kernel soft deadlock multiple times, thus saving CPU processing and output resources.

[0110] S240, the CPU obtains the thread information of the first thread.

[0111] It should be noted that the thread information of the first thread in S240 is consistent with the thread information of the first thread in S120. For a detailed description of the thread information of the first thread in S240, please refer to the relevant description of S120 above, which will not be repeated here.

[0112] It should be understood that there are three possible scenarios for the first thread mentioned above, as follows:

[0113] Case 1: When the first thread is waiting to acquire the first target lock, the thread information of the first thread contains the first lock identifier.

[0114] Case 2: When the first thread holds the first target lock, the first lock identifier is not present in the thread information of the first thread.

[0115] Case 3: When the first thread is not waiting to acquire the first target lock and the first thread does not hold the first target lock, the first lock identifier is not present in the thread information of the first thread.

[0116] Therefore, the thread information of the first thread may contain a first lock identifier (e.g., case 1 above) or it may not contain a first lock identifier (e.g., cases 2 and 3 above).

[0117] Wherein: if the first lock identifier is not present in the thread information of the first thread, the CPU executes the following S250-S260.

[0118] If the first lock identifier exists in the thread information of the first thread, the CPU executes the following steps S270-S280.

[0119] S250 and CPU generate the second analysis result.

[0120] It should be understood that since the first thread is not a thread waiting to acquire the lock, and the first thread is the thread that triggers the OS to cause a kernel soft deadlock (i.e., a second kernel soft lock), it can be determined that the first thread is a thread that occupies the CPU resource for a long time.

[0121] It should be noted that when the task executed by the first thread contains an infinite loop, the first thread will remain in the infinite loop and will not be able to break out of the loop, thus causing the first thread to continuously occupy the CPU resources, resulting in a kernel soft deadlock in the aforementioned OS. Similarly, when the task executed by the first thread contains an infinite recursion, the first thread will remain in the loop corresponding to the infinite recursion and will not be able to break out of the recursion, thus causing the first thread to continuously occupy the CPU resources, resulting in a kernel soft deadlock in the aforementioned OS.

[0122] Based on this, the second analysis result is used to indicate that there is a delay fault in the first thread; wherein, the delay fault includes at least: infinite loop and infinite recursion.

[0123] Specifically: When the first thread belongs to situation 2 above, the specific content of the second analysis result can be: The reason for the kernel soft deadlock is that there is a delay fault (such as an infinite loop) in the first thread, which causes the first thread to occupy the first target lock for a long time.

[0124] When the first thread falls under situation 3 above, the specific content of the second analysis result may be: the reason for the kernel soft deadlock is that the first thread has a delay fault, which causes the first thread to occupy CPU resources for a long time and cannot release them.

[0125] S260, CPU outputs the second analysis result.

[0126] It should be noted that the implementation of S260 is similar to that of S140. For a detailed description of S260, please refer to the relevant description of S140 above. It will not be repeated here.

[0127] In the above embodiment, when the first thread does not contain a first lock identifier in its thread information and the first thread is the thread that triggers the OS to cause a kernel soft deadlock, the CPU generates a second analysis result. This second analysis result is used to indicate that there is a delay fault in the first thread (specifically, an infinite loop and / or dead recursion). Then, the CPU outputs the second analysis result so that the user can know from the output of the second analysis result that the cause of the above kernel soft deadlock is the existence of an infinite loop and dead recursion in the first thread, thereby improving the user's processing efficiency for the kernel soft deadlock.

[0128] Optionally, after S260 above, the kernel soft deadlock analysis method further includes: the CPU updating the first soft deadlock identifier using the current soft deadlock identifier, so that the updated first soft deadlock identifier becomes the current soft deadlock identifier. This allows the CPU to determine whether to execute the kernel soft deadlock analysis method provided in this application embodiment the next time it detects a kernel soft deadlock (hereinafter referred to as: third kernel soft deadlock) in the OS, based on the updated first soft deadlock identifier and the identifier of the third kernel soft deadlock.

[0129] S270 and CPU generate the first analysis result of kernel soft deadlock based on the lock information of the first target lock.

[0130] It should be noted that the implementation of S270 is similar to that of S130. For a detailed description of S270, please refer to the relevant description of S130 above. It will not be repeated here.

[0131] S280, CPU outputs the first analysis result.

[0132] It should be noted that the implementation of S280 is similar to that of S260. For a detailed description of S280, please refer to the relevant description of S260 above. It will not be repeated here.

[0133] In the above embodiment, when a first lock identifier exists in the first thread information, a first analysis result is generated and output based on the lock information of the first target lock to indicate that the thread holding the first target lock is the second thread. Here, the first thread is the thread that triggers the OS to cause a kernel soft deadlock, and the first target lock causes the first thread to wait to acquire the lock. When a first lock identifier does not exist in the first thread information, a second analysis result is generated and output to indicate that there is a delay fault (specifically: infinite loop and / or dead recursion) in the first thread. This allows the user to know the cause of the kernel soft deadlock based on the output first or second analysis result, thus improving the user's processing efficiency for the kernel soft deadlock.

[0134] It should be noted that, based on the first analysis results above, users can know that the cause of the kernel soft deadlock in the OS is that the first target lock that the first thread is waiting to acquire is occupied by the second thread for a long time. However, users do not know the reason why the second thread occupies the first target lock for a long time.

[0135] Based on this, combined Figure 3 like Figure 4 As shown, after S280 above, the kernel soft deadlock analysis method provided in this application embodiment further includes: S310-S360.

[0136] S310, the CPU obtains the thread information of the second thread.

[0137] It should be noted that the implementation of 310 above is similar to the implementation of S120 above. For a detailed description of the implementation of S310, please refer to the relevant description of S120 above. It will not be repeated here.

[0138] S320: The CPU determines whether the thread information of the second thread includes the second lock identifier.

[0139] The aforementioned second lock identifier is used to indicate the second target lock that the second thread is waiting to acquire; that is, the lock identifier of the second target lock that the second thread is waiting to acquire is the second lock identifier.

[0140] It should be noted that the lock types of the first target lock and the second target lock can be the same or different. In this specific embodiment, the lock type of the second target lock is not specifically limited.

[0141] If a second lock identifier exists in the thread information of the second thread, the CPU executes the following steps S330-S340.

[0142] If the second lock identifier is not present in the thread information of the second thread, the CPU executes the following steps S350-S360.

[0143] Based on the lock information of the second target lock, the S330 and CPU generate the third analysis result of kernel soft deadlock.

[0144] The aforementioned third analysis result is used to indicate that the thread holding the second target lock is the third thread; the lock information of the second target lock includes the identifier of the third thread.

[0145] It should be understood that the first analysis result indicates that the cause of the kernel soft deadlock is that the first target lock that the first thread is waiting to acquire is held by the second thread; while the third analysis result indicates that the thread holding the second target lock is the third thread, where the second target lock is the lock that the second thread is waiting to acquire. Therefore, the cause of the kernel soft deadlock is that the first target lock that the first thread is waiting to acquire is held by the second thread for a long time, and the reason the second thread holds the first target lock for a long time is that the second target lock that the second thread is waiting to acquire is held by the third thread for a long time. Consequently, without the third thread releasing the second target lock, the second thread cannot acquire it. Because the second thread is in a state of waiting to acquire the second target lock, it cannot release the first target lock, thus keeping the first thread in a state of waiting to acquire the first target lock, resulting in a kernel soft deadlock in the OS.

[0146] S340 and CPU output the third analysis result.

[0147] It should be noted that the implementation methods of S330-S340 are similar to those of S130-S140. For a detailed description of the implementation methods of S330-S340, please refer to the relevant descriptions of S130-S140 above, which will not be repeated here.

[0148] S350 and CPU generate the fourth analysis result.

[0149] The fourth analysis result above is used to indicate that the aforementioned delay fault exists in the second thread.

[0150] It should be understood that the first analysis result above indicates that the cause of the kernel soft deadlock is that the first target lock that the first thread is waiting to acquire is occupied by the second thread, while the fourth analysis result above indicates that there is a delay fault in the second thread. It can be seen that the cause of the kernel soft deadlock is that the first target lock that the first thread is waiting to acquire is occupied by the second thread for a long time, and the reason why the second thread occupies the first target lock for a long time is because there is a delay fault (such as an infinite loop) in the second thread. As a result, if the second thread cannot break out of the infinite loop, it will continue to occupy the first target lock, so that the first thread will always be in the state of waiting to acquire the first target lock, thereby causing the OS to experience a kernel soft deadlock.

[0151] S360 and CPU output the fourth analysis result.

[0152] It should be noted that the implementation methods of S350-S360 are similar to those of S250-S260. For a detailed description of the implementation methods of S350-S360, please refer to the relevant descriptions of S250-S260 above, which will not be repeated here.

[0153] In the above embodiment, after the CPU outputs an indication that the first target lock, which the first thread is waiting to acquire, is being held by the second thread for an extended period, the CPU acquires the thread information of the second thread. If the second thread's thread information contains a second lock identifier, the CPU generates and outputs a result indicating that the reason for the second thread's prolonged holding of the first target lock is that the second target lock, which the second thread is waiting to acquire, is being held by the third thread for an extended period (i.e., the third analysis result). Here, the lock identifier of the second target lock is the second lock identifier, and the lock information of the second target lock includes the identifier of the third thread. If the second thread's thread information does not contain a second lock identifier, the CPU generates and outputs a result indicating that the reason for the second thread's prolonged holding of the first target lock is a delay fault in the second thread (i.e., the fourth analysis result). This allows the user to understand the reason for the second thread's prolonged holding of the first target lock based on the output of the third or fourth analysis result, thereby enabling the user to quickly locate the bug causing the kernel soft deadlock and further improving the user's efficiency in handling the kernel soft deadlock.

[0154] Optionally, in another embodiment, after the CPU generates a first analysis result indicating that the first target lock that the first thread is waiting to acquire is occupied by the second thread, it does not output the first analysis result. Instead, it generates the third or fourth analysis result based on the thread information of the second thread (e.g., the CPU generates the third analysis result). Then, the CPU merges the first analysis result and the third analysis result and outputs the merged analysis result. The merged analysis result indicates that the first target lock that the first thread is waiting to acquire is occupied by the second thread for a long time. The reason why the second thread occupies the first target lock for a long time is that the third thread occupies the second target lock that the second thread is waiting to acquire for a long time.

[0155] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0156] This application embodiment can divide the analysis device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0157] When dividing each function into modules according to its corresponding function. Figure 5 A schematic diagram of a possible structure of the analytical apparatus involved in the above embodiments is shown. For example... Figure 5 As shown, the analysis device includes a transceiver unit 501 and a processing unit 502.

[0158] The transceiver unit 501 is used to obtain the thread information of the first thread in the event of a kernel soft deadlock in the OS; for example, by executing step S120 in the above method embodiment.

[0159] The processing unit 502 is used to generate a first analysis result of kernel soft deadlock based on the lock information of the first target lock when the thread information of the first thread includes the first lock identifier; for example, by executing step S130 in the above method embodiment.

[0160] The transceiver unit 501 is used to output the first analysis result; for example, to execute step S140 in the above method embodiment.

[0161] Optionally, the processing unit 502 is used to generate a second analysis result if the first lock identifier is not present in the thread information of the first thread; for example, by executing step S250 in the above method embodiment.

[0162] The transceiver unit 501 is used to output the second analysis result; for example, to execute step S260 in the above method embodiment.

[0163] Optionally, the transceiver unit 501 is used to obtain thread information of the second thread; for example, by executing step S310 in the above method embodiment.

[0164] The processing unit 502 is used to generate a third analysis result of kernel soft deadlock based on the lock information of the second target lock; for example, by executing step S330 in the above method embodiment.

[0165] The transceiver unit 501 is also used to output the third analysis result; for example, to execute step S340 in the above method embodiment.

[0166] Optionally, the transceiver unit 501 is used to obtain the thread information of the first thread when the first soft deadlock identifier is different from the current soft deadlock identifier; for example, by executing steps S230-S240 in the above method embodiment.

[0167] Optionally, the processing unit 502 is used to update the first soft deadlock identifier using the current soft deadlock identifier, so that the updated first soft deadlock identifier is the same as the current soft deadlock identifier.

[0168] Optionally, the analysis device further includes a storage unit 503; the storage unit 503 is used to persist the first analysis result and the CPU call stack information to the hard disk in the computing device.

[0169] Optionally, the processing unit 502 is used to add the first lock identifier to the thread information of the first thread when the first thread is in a state of waiting to acquire the first target lock.

[0170] Each unit of the above-mentioned analysis device can also be used to perform other actions in the above-mentioned method embodiments. All relevant content of each step involved in the above-mentioned method embodiments can be referred to the functional description of the corresponding functional module, and will not be repeated here.

[0171] This application also provides a processor for running a program, which executes any of the methods described above that are executed by the CPU.

[0172] This application also provides a computing device, including a memory and a processor, wherein the memory is electrically connected to the processor; the memory is used to store program instructions, and the processor executes the program instructions to implement any of the methods executed by the CPU described above.

[0173] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computing device, cause the computing device to perform any of the methods executed by the CPU described above.

[0174] For explanations of the relevant content and descriptions of the beneficial effects in any of the computer-readable storage media provided above, please refer to the corresponding embodiments described above, which will not be repeated here.

[0175] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0176] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0177] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0178] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0179] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0180] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0181] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for analyzing kernel soft deadlock, characterized in that, The method is applied to a processor CPU in a computing device, and the method includes: When the first thread is in a state of waiting to acquire the first target lock, the first lock identifier of the first target lock is added to the thread information of the first thread; When the second thread acquires the first target lock, the identifier of the second thread is added to the lock information of the first target lock; In the event of a kernel soft deadlock in the operating system (OS), obtain the thread information of the first thread; the first thread is the thread that triggered the kernel soft deadlock. If the thread information includes a first lock identifier, the lock indicated by the first lock identifier is determined to be the first target lock that the first thread is waiting to acquire; Based on the identifier of the second thread included in the lock information of the first target lock, a first analysis result of the kernel soft deadlock is generated; the first analysis result is used to indicate that the thread occupying the first target lock is the second thread; Output the first analysis result.

2. The method according to claim 1, characterized in that, The first analysis result is also used to indicate that the second thread occupies the first target lock for a first duration; the first lock information includes the first duration; and / or; The first analysis result is also used to indicate the lock type of the first target lock. The first lock information includes the lock type of the first target lock, which includes spin locks and read-write locks.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If the first lock identifier is not present in the thread information, a second analysis result is generated. The second analysis result is used to indicate that there is a delay fault in the first thread. The delay fault includes at least: infinite loop and dead recursion. Output the second analysis result.

4. The method according to any one of claims 1-2, characterized in that, The method further includes: Obtain the thread information of the second thread; if the thread information of the second thread includes a second lock identifier, the second lock identifier is used to indicate that the second thread is waiting to acquire a second target lock; Based on the lock information of the second target lock, a third analysis result of the kernel soft deadlock is generated; the third analysis result is used to indicate that the thread occupying the second target lock is a third thread; the lock information of the second target lock includes: the identifier of the third thread; Output the third analysis result.

5. The method according to any one of claims 1-2, characterized in that, The step of obtaining the thread information of the first thread includes: When the first soft deadlock identifier is different from the current soft deadlock identifier, the thread information of the first thread is obtained; wherein, the first soft deadlock identifier is the identifier of the kernel soft deadlock that the CPU last detected from the OS; and the current soft deadlock identifier is the identifier of the kernel soft deadlock that the CPU currently detects from the OS.

6. The method according to claim 5, characterized in that, After outputting the first analysis result, the method further includes: Update the first soft deadlock identifier using the current soft deadlock identifier, so that the updated first soft deadlock identifier is the same as the current soft deadlock identifier.

7. The method according to any one of claims 1-2, characterized in that, The method further includes: The first analysis result and the CPU call stack information are persisted to the hard disk in the computing device; the call stack information includes: the function identifier of the function called by the CPU, the duration of the CPU execution of the function, and the call relationship between the functions called by the CPU.

8. A processor, characterized in that, The processor is used to execute the method described in any one of claims 1-7.

9. A computing device, characterized in that, The computing device includes a memory and a processor; the memory and the processor are electrically connected; the memory is used to store program instructions, and the processor is used to execute the program instructions to enable the computing device to implement the method as described in any one of claims 1-7.

Images