Program deadlock detection method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a program deadlock detection method and device, electronic equipment and a storage medium. The program deadlock detection method comprises the steps of obtaining a first lock of a target library file of a first programming language in response to a first object, and obtaining lock information in the target library file; detecting whether the first object meets a preset deadlock condition corresponding to the first lock or not according to the lock information; the preset deadlock condition comprises at least one of the following items: whether the first lock is repeatedly used by the first object; when the first lock is used by the plurality of objects, the use sequence of the first lock by the plurality of objects is wrong; the plurality of objects comprise a first object; and under the condition that the first object meets the preset deadlock condition, determining that the first object is deadlocked. According to the deadlock detection method and device, the generated and potential deadlock conditions can be rapidly and accurately detected in the program running process, the deadlock detection accuracy and efficiency are improved, the method and device do not depend on a third-party tool or modify program source codes, and the space overhead in target library files and programs is reduced.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a method, apparatus, electronic device and storage medium for detecting program deadlock. Background Technology

[0002] Deadlock is a common and troublesome problem in concurrent programming. Deadlock occurs when two or more threads are waiting for each other to release resources, causing the program to become stuck in a state of perpetual waiting. Taking Go (Golang) as an example, Go has powerful built-in concurrency mechanisms and goroutines, which makes it easy for programmers to write efficient concurrent programs, but also introduces a greater risk of deadlock. Therefore, deadlock detection during program execution is essential.

[0003] Currently, several methods exist for deadlock detection in Go programs, but each has its limitations. For example, the Go runtime includes basic deadlock detection; when all goroutines are in a waiting state, it throws a "fatal error: all goroutines are asleep - deadlock!" error. However, this method cannot detect deadlocks occurring in only some goroutines. Additionally, Go developers often use third-party concurrency debugging tools to address deadlock detection. These tools integrate various analysis tools to detect concurrency issues in the code. However, this reliance on third-party tools is lagging; it can only detect deadlocks after they occur, not identify potential deadlocks.

[0004] Therefore, how to detect potential deadlock problems during program execution is one of the urgent problems to be solved. Summary of the Invention

[0005] The purpose of this application is to provide a program deadlock detection method, apparatus, electronic device, and storage medium to solve the problem that deadlock situations that have occurred and those that have not yet occurred (i.e., potential) cannot be detected in a timely and accurate manner during program execution.

[0006] To solve the above-mentioned technical problems, the embodiments of this application are implemented as follows: On the one hand, embodiments of this application provide a method for detecting program deadlock, including: In response to the first object acquiring a first lock on a target library file of a first programming language, lock information is acquired in the target library file; Based on the lock information, it is detected whether the first object satisfies the preset deadlock condition corresponding to the first lock; the preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects, the order in which the multiple objects use the first lock is incorrect; the multiple objects include the first object. If the first object satisfies the preset deadlock condition, it is determined that the first object has deadlocked.

[0007] On the other hand, embodiments of this application provide a program deadlock detection device, including: The acquisition module is configured to acquire lock information in the target library file in response to the first object acquiring a first lock of the target library file of the first programming language; The detection module is used to detect whether the first object satisfies the preset deadlock condition corresponding to the first lock based on the lock information; the preset deadlock condition includes at least one of the following: whether the first lock is used repeatedly by the first object; when the first lock is used by multiple objects, the order in which the multiple objects use the first lock is incorrect; the multiple objects include the first object; The determination module is used to determine that the first object has deadlocked if the first object satisfies the preset deadlock condition.

[0008] In another aspect, embodiments of this application provide an electronic device, including a processor and a memory electrically connected to the processor, the memory storing a computer program, and the processor being used to call and execute the computer program from the memory to implement the above-described program deadlock detection method.

[0009] In another aspect, embodiments of this application provide a computer-readable storage medium for storing a computer program that can be executed by a processor to implement the above-described program deadlock detection method.

[0010] In another aspect, embodiments of this application provide a computer program product, including a computer program, which is executed by a processor to implement the above-described program deadlock detection method.

[0011] The technical solution of this application embodiment, in response to a first object acquiring a first lock on a target library file of a first programming language, obtains lock information from the target library file and checks whether the first object meets the preset deadlock condition corresponding to the first lock based on the lock information. If the first object meets the preset deadlock condition, it is determined that the first object has deadlocked. The preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects (including the first object); or when the order in which multiple objects use the first lock is incorrect. It is evident that as long as the first object acquires the first lock on the target library file of the first programming language, a deadlock detection action is triggered. Therefore, it is possible to quickly and accurately detect both existing and potential deadlocks during program execution, avoiding the problem that some deadlock situations (such as potential deadlocks) cannot be detected in time, thus preventing the program from running normally and greatly improving the accuracy and efficiency of deadlock detection. Furthermore, since the lock information is stored in the target library file, the program source code corresponding to the target library file can obtain the lock information and perform deadlock detection based on the lock information. Therefore, there is no need to integrate third-party tools into the program, thereby reducing the space overhead within the program. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in one or more embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in one or more embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic flowchart of a program deadlock detection method according to an embodiment of this application; Figure 2 This is a schematic structural diagram of the source code corresponding to a first programming language according to an embodiment of this application; Figure 3 This is a schematic structural diagram of a coroutine repeatedly acquiring a lock according to an embodiment of this application; Figure 4 This is a schematic structural diagram illustrating an error in the order of lock usage according to an embodiment of this application; Figure 5 This is a schematic flowchart of a program deadlock detection method according to another embodiment of this application.

[0014] Figure 6 This is a schematic block diagram of a program deadlock detection device according to an embodiment of this application; Figure 7This is a schematic block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0015] This application provides a method, apparatus, electronic device, and storage medium for detecting program deadlock, in order to solve the problem that deadlock situations that have occurred and those that have not yet occurred (i.e., potential deadlocks) cannot be detected in a timely and accurate manner during program execution.

[0016] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0017] The deadlock detection method provided in this application can be executed by an electronic device or by software installed in an electronic device. Specifically, the electronic device can be a terminal device or a server device. The terminal device can include smartphones, laptops, smart wearable devices, vehicle terminals, etc., and the server device can include an independent physical server, a server cluster composed of multiple servers, or a cloud server capable of cloud computing.

[0018] The deadlock detection method provided in this application can be applied to various computer architectures such as ARM and x86, and can be used on various operating systems such as Linux and Windows. It includes, but is not limited to, deadlock detection of programs without modifying source code in multiple fields such as microservices, Internet, communications, and embedded systems.

[0019] Figure 1 This is a schematic flowchart of a program deadlock detection method according to an embodiment of this application, as shown below. Figure 1 As shown, the program deadlock detection method includes the following steps S102-S106: S102, in response to the first object acquiring the first lock of the target library file of the first programming language, acquire the lock information in the target library file.

[0020] The first object can be a thread or a coroutine within a thread. The target library file is the underlying library file of the first programming language, which is the library file that the application needs to reference at runtime. For example, an application written in the first programming language needs to call the target library file of the first programming language at runtime. The lock type of the first lock is not limited; it can be a mutex lock or a read-write lock.

[0021] The source code of the target library file includes a deadlock detection algorithm. When the application calls the target library file, it executes the source code of the target library file. When the first object in the application acquires the first lock of the target library file, the deadlock detection algorithm in the source code of the target library file is triggered. The execution process of the deadlock detection algorithm includes steps S102-S106.

[0022] The lock information in the target library file is used to record information related to the currently used lock. Lock information may include at least one of the following: the lock identifier of the currently used second lock, the object identifier of the second object using the second lock, the stack information of the second object, the order in which the second object uses the second lock, and the number of times the second object uses the lock. The second object can be a thread or a coroutine within a thread.

[0023] Optionally, lock identification information refers to information that uniquely identifies the lock, such as the lock name, lock number, lock pointer, etc. Object identification information refers to information that uniquely identifies the object, such as the object name, object sequence number, etc. If the object is a thread, the object identification information is thread identification information, such as thread name, thread sequence number, etc.; if the object is a coroutine within a thread, the object identification information is coroutine identification information, such as coroutine name, coroutine sequence number, etc. The stack information of the second object can provide information on the second object's acquisition of the lock. For example, the stack information shows that the second object acquired the lock on line N of the object's code (thread code or coroutine code). The usage order information of the second object on the second lock is used to characterize the order relationship between the second object's use of the second lock and its use of other locks. The lock usage count of the second object is used to characterize the number of times the second object uses the lock. It can be understood as counting the number of times the second object uses the lock; each time the lock is used, the count is incremented by 1, and the lock usage count of the second object is incremented by 1.

[0024] S104, based on the lock information, detect whether the first object meets the preset deadlock condition corresponding to the first lock; the preset deadlock condition includes at least one of the following: whether the first lock is used repeatedly by the first object; when the first lock is used by multiple objects; or when the order in which multiple objects use the first lock is incorrect.

[0025] Among them, multiple objects include the first object.

[0026] Optionally, if multiple objects use the first lock, and the order in which they use the first lock differs, then the order in which they use the first lock is considered incorrect. Taking coroutines as an example, coroutine A uses locks 1 and 2 in the following order: lock 1 → lock 2; coroutine B also uses locks 1 and 2 in the following order: lock 2 → lock 1. It can be seen that coroutines A and B use lock 1 (or lock 2) in different orders, and in this case, it is considered that coroutines A and B have used lock 1 (or lock 2) in an incorrect order.

[0027] S106, if the first object meets the preset deadlock conditions, it is determined that the first object has deadlocked.

[0028] In this embodiment, before executing step S102, the following steps are performed in advance: replacing the first standard library file of the first programming language with a target library file, wherein the source code of the language corresponding to the target library file includes a deadlock detection algorithm; and adding a second standard library file to the first programming language. The second standard library file and the first standard library file have the same file content.

[0029] Optionally, the first standard library file is the original low-level library file of the first programming language. The first standard library file of the first programming language is copied and renamed the second standard library file. Then, the second standard library file is added to the first programming language. Simultaneously, deadlock detection algorithm code is added to the language source code corresponding to the first standard library file, thus obtaining the target library file. In other words, the first standard library file of the first programming language is replaced with the target library file. Since the language source code corresponding to the first standard library file does not include deadlock detection algorithm code, it lacks deadlock detection functionality. By adding deadlock detection algorithm code to the language source code of the first standard library file, the program source code of the replaced target library file gains deadlock detection functionality, thus eliminating the need for third-party tools during deadlock detection.

[0030] Figure 2 This is a schematic structural diagram of the source code corresponding to a first programming language according to an embodiment of this application. For example... Figure 2 As shown, the source code for the first programming language includes object library files, a second standard library file, and other library files. The second standard library file and the first standard library file (i.e., the original underlying library file) of the first programming language have the same content, meaning their corresponding source code is identical. The second standard library file includes mutexes, read-write locks, wait sets, etc., where the wait set includes process information and / or coroutine information for the currently waiting lock. The object library file includes the same library file content as the second standard library file (such as...). Figure 2 In addition to the original library file contents shown in the image, it also includes a deadlock detection algorithm.

[0031] Furthermore, directly modifying the first standard library file can cause circular references, and some programming languages ​​(such as Go) do not allow circular references between library files. Therefore, adding a second standard library file to the first programming language allows other library files to modify their code that references the first standard library file to reference the second standard library file instead, thus resolving the circular reference problem. Moreover, when an application written in the first programming language needs to perform deadlock detection, the deadlock detection algorithm in the target library file is triggered when the target library file is called, thus eliminating the need to modify the application's own code.

[0032] The technical solution of this application embodiment, in response to a first object acquiring a first lock on a target library file of a first programming language, obtains lock information from the target library file and checks whether the first object meets the preset deadlock condition corresponding to the first lock based on the lock information. If the first object meets the preset deadlock condition, it is determined that the first object has deadlocked. The preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects (including the first object); or when the order in which multiple objects use the first lock is incorrect. It is evident that as long as the first object acquires the first lock on the target library file of the first programming language, a deadlock detection action will be triggered. Therefore, it is possible to quickly and accurately detect both existing and potential deadlocks during program execution, avoiding the problem that some deadlock situations (such as potential deadlocks) cannot be detected in time, thus preventing the program from running normally and greatly improving the accuracy and efficiency of deadlock detection. Furthermore, since the lock information is stored in the target library file, the source code of the language corresponding to the target library file can obtain the lock information and perform deadlock detection based on the lock information. Therefore, there is no need to integrate third-party tools into the program, thereby reducing the space overhead within the program.

[0033] In one embodiment, considering the high efficiency of dictionary lookups, lock information can be represented using a dictionary data structure. Optionally, lock information includes at least one of the following four data structures A1-A4: Data structure A1: The first correspondence between the lock identifier information of the currently used second lock and the object identifier information of the second object, where the second object is the thread or coroutine using the second lock.

[0034] Data structure A1 is used to record the lock identifier information of the lock and the object identifier information of the object that holds the lock. Based on data structure A1, it is possible to detect whether the same object has repeatedly acquired the lock. Optionally, data structure A1 includes the correspondence between the pointer to the second lock and the object sequence number of the second object that holds the second lock.

[0035] The second correspondence between data structure A2, the lock identifier information of the second lock, the object identifier information of the second object, and the stack information of the second object.

[0036] Optionally, data structure A2 includes the correspondence between the pointer to the currently used second lock, the object sequence number of the second object using the second lock, and the stack information of the second object.

[0037] The difference between data structure A2 and data structure A1 is that data structure A1 only records the object identification information of objects that successfully acquire the lock. Successfully acquiring the lock means that the object owns and locks the lock. However, in practical applications, a lock can be acquired (or used) by multiple objects simultaneously. Therefore, it is necessary to record the information of all objects currently acquiring the same lock, which is where data structure A2 comes in. Data structure A2 records the object identification information and stack information of all objects currently using the same lock.

[0038] Taking coroutines as an example, coroutines A and B simultaneously acquire lock 1. Coroutine A successfully acquires lock 1 and holds it. Coroutine B then needs to wait for coroutine A to release lock 1 before it can acquire it; at this point, coroutine B is in a waiting state. Therefore, data structure A1 only records the coroutine sequence number of the coroutine that successfully acquired the lock (i.e., coroutine A), while data structure A2 records both the coroutine sequence number and stack information of the coroutine that successfully acquired the lock (i.e., coroutine A), and the coroutine sequence number and stack information of the coroutine in a waiting state (i.e., coroutine B).

[0039] The third correspondence between data structure A3, the lock identifier information of the second lock, the object identifier information of the second object, and the usage order information of the second object on the second lock.

[0040] Data structure A3 records the order in which objects use multiple locks. Based on data structure A3, it can be determined whether different objects use the same multiple locks in the same order. Since multiple locks being used in different orders on different objects (e.g., two locks being used in reverse order on different objects) can lead to potential deadlock problems, data structure A3 can be used to detect whether the order in which different objects use locks is incorrect, thereby detecting whether a deadlock has occurred.

[0041] Data structure A4, the fourth correspondence between the object identification information of the second object and the number of times the lock of the second object is used.

[0042] In this embodiment, the above four data structures are used to record information related to the locks in use. The fast lookup characteristics of the dictionary data structure make deadlock detection faster and more accurate, significantly reducing the time cost of the deadlock detection process. Furthermore, the dictionary data structure is also space-saving, ensuring that the recorded lock information does not excessively occupy space in the target library file, thus greatly saving space costs.

[0043] In one embodiment, when detecting whether the first object meets the preset deadlock condition corresponding to the first lock based on the lock information, the following actions B1-B3 can be performed: Action B1: Based on the lock information, check whether the first lock has been reused by the first object.

[0044] Action B2: If the first lock is reused by the first object, determine that the first object meets the preset deadlock condition.

[0045] Action B3: If the first lock is not reused by the first object, check if the order in which multiple objects use the first lock is incorrect; if the order in which multiple objects use the first lock is incorrect, determine that the first object meets the preset deadlock condition.

[0046] Optionally, if the first lock is not reused by the first object and the order in which multiple objects use the first lock is correct, it is determined that the first object does not meet the preset deadlock condition. In this case, it can be determined that the first object has not deadlocked, or other detection methods can be combined to further detect whether the first object has deadlocked.

[0047] In this embodiment, by first detecting whether the first lock is reused by the first object, it is determined that the first object meets the preset deadlock condition if the first lock is reused by the first object. If the first lock is not reused by the first object, it is further detected whether the usage order of the first lock by multiple objects is incorrect. If the usage order of the first lock by multiple objects is incorrect, it is determined that the first object meets the preset deadlock condition. This method can quickly and accurately detect deadlock situations that have occurred and those that have not yet occurred (i.e., potential) during program execution, greatly improving the accuracy and efficiency of deadlock detection.

[0048] In one embodiment, the lock information includes a first correspondence, namely, data structure A1. When detecting whether the first lock is reused by the first object (i.e., action B1) based on the lock information, it can be determined that the first lock is reused by the first object if the first correspondence includes the correspondence between the lock identifier information of the first lock and the object identifier information of the first object.

[0049] The first correspondence includes the relationship between the lock identifier information of the first lock and the object identifier information of the first object, indicating that the first object currently holds the first lock. If the first object acquires the first lock again, the serial nature of program execution will prevent the first object from releasing the first lock before acquiring it, thus preventing it from holding the first lock and resulting in a deadlock.

[0050] Optionally, based on the first correspondence, the object identifier information of the object currently holding the first lock can be determined. Based on this object identifier information, it can be determined whether the object currently holding the first lock is the first object. If it is, then it is determined that the first lock has been reused by the first object. If not, then it is determined that the first lock has not been reused by the first object.

[0051] Figure 3 This is a schematic structural diagram of a coroutine repeatedly acquiring a lock according to an embodiment of this application. For example... Figure 3 As shown, the coroutine currently holds lock 1 and lock 2. If the coroutine tries to acquire lock 1 again, it will result in the coroutine repeatedly acquiring lock 1, eventually leading to a deadlock. Figure 3 This is merely an illustrative example of a coroutine repeatedly acquiring a lock. The situation of a thread repeatedly acquiring a lock is similar to that of a coroutine and will not be repeated here.

[0052] In one embodiment, the lock information includes a first correspondence and a third correspondence, namely, data structure A1 and data structure A3. When detecting whether an error has occurred in the order in which multiple objects use the first lock (i.e., action B3), the following steps can be performed: First, based on the first correspondence, determine the third lock used by the first object, in addition to the first lock. The third lock is any other lock used by the first object, which may include one or more locks.

[0053] Secondly, based on the third correspondence, determine whether there exists a third object that uses both the first and third locks, and that the third object is different from the first object.

[0054] Furthermore, if a third object exists, then if the first usage order information and the second usage order information are different, it is determined that multiple objects have an incorrect usage order of the first lock.

[0055] The first usage order information is used to characterize the order in which the first object uses the first lock and the third lock, and the second usage order information is used to characterize the order in which the third object uses the first lock and the third lock.

[0056] In this embodiment, an error in the order of lock usage refers to the situation where two identical locks are simultaneously contested by two objects. If the locking order of these two locks in the two objects is different, it may cause the two objects to wait for each other to release the lock, resulting in a deadlock.

[0057] For example, the first object is coroutine A, the third object is coroutine B, and the first lock is lock 2. Based on the first correspondence, it is determined that coroutine A uses lock 2 while also using lock 3. Based on the third correspondence, it is determined that coroutine B also uses locks 2 and 3. That is, a third object (i.e., coroutine B) exists. At this point, the first usage order information for locks 2 and 3 by coroutine A is determined, as well as the second usage order information for locks 2 and 3 by coroutine B. If the first and second usage order information differ, it is determined that the usage order of lock 2 by coroutines A and B is incorrect.

[0058] Figure 4 This is a schematic structural diagram illustrating an error in the order of lock usage according to an embodiment of this application. For example... Figure 4 As shown, according to the order of lock usage, the order in which coroutine A uses locks 2 and 3 can be represented as: lock 2 → lock 3. The order in which coroutine B uses locks 2 and 3 can be represented as: lock 3 → lock 2. Clearly, the order in which coroutines A and B use locks 2 and 3 is exactly reversed, indicating that the order in which they use lock 2 is incorrect, and a deadlock has occurred. Figure 4 This is merely an illustrative example of a situation where multiple coroutines use locks in the wrong order. The situation where multiple threads use locks in the wrong order is similar to that of coroutines and will not be explained again.

[0059] In one embodiment, after detecting whether the first object meets the preset deadlock condition corresponding to the first lock based on the lock information, the first lock is acquired if the first object does not meet the preset deadlock condition. During the acquisition of the first lock, the acquisition time of the first object for the first lock is determined. If the acquisition time is greater than or equal to a preset time threshold, it is determined that the first object has deadlocked.

[0060] Optionally, during the process of the first object acquiring the first lock, the first object times the acquisition time. If the acquisition time of the first object for the first lock is less than a preset time threshold, it indicates that the first object has acquired the first lock sequentially and no deadlock has occurred. If the acquisition time of the first object for the first lock is greater than or equal to the preset time threshold, it indicates that the locking time has timed out, and a deadlock has occurred for the first object.

[0061] In this embodiment, considering that timeout locking can also lead to deadlock, the acquisition time is timed during the lock acquisition process. This allows for quick and accurate determination of whether the object has successfully acquired the lock within a preset time threshold, thereby quickly and accurately detecting deadlock.

[0062] In one embodiment, after acquiring the first lock, the lock information is updated in response to the first object acquiring the first lock.

[0063] Updating the lock information may include at least one of the following: In the first correspondence of data structure A1, add the correspondence between the lock identifier information of the first lock and the object identifier information of the first object.

[0064] In the second correspondence of data structure A2, add the correspondence between the lock identifier information of the first lock, the object identifier information of the first object, and the stack information of the first object.

[0065] In the third correspondence of data structure A3, update the usage order information of the first object to the first lock.

[0066] In the fourth correspondence of data structure A4, update the lock usage count of the first object.

[0067] In one embodiment, after determining that a deadlock has occurred in the first object, deadlock information is output. The deadlock information includes at least one of the following: deadlock cause, lock identifier information of the first lock, object identifier information of the first object, and stack information of the first object. The deadlock cause is determined based on deadlock detection. For example, if a deadlock is determined when it is detected that the first object is repeatedly using the first lock, then the deadlock cause is the repeated use of the first lock by the first object. If a deadlock is determined when it is detected that multiple objects are using the first lock in an incorrect order, then the deadlock cause is the incorrect order of use of the first lock by multiple objects. If a deadlock is determined when it is detected that the time taken for the first object to acquire the first lock is greater than or equal to a preset time threshold, then the deadlock cause is that the first object timed out of acquiring the first lock.

[0068] In this embodiment, by outputting deadlock information, technicians can promptly obtain relevant information about the deadlock situation and perform related maintenance based on the deadlock information.

[0069] Figure 5 This is a schematic flowchart illustrating a program deadlock detection method according to another embodiment of this application. In this embodiment, Go is used as the first programming language, and the first lock can be a mutex lock or a read-write lock. The underlying library file of the Go language is called the synchronization library. Other library files or applications written in Go will call the Go language synchronization library at runtime.

[0070] Suppose that in a real-world development environment, a developer makes a logical error while writing code, causing the system to malfunction. In this case, the deadlock detection method provided in this application's embodiments is needed to detect deadlock, thereby identifying the deadlock problem and finding its cause. Of course, this is only an illustrative example; any application written in the first programming language can use the deadlock detection algorithm in that programming language for deadlock detection.

[0071] like Figure 5 As shown, the program deadlock detection method includes the following steps S501-S510: S501, copy the synchronization library and rename it to "Synchronization Library A" and add it to the Go language; modify the code in the Go language source code that references the synchronization library to reference Synchronization Library A; and add a deadlock detection algorithm to the synchronization library to generate the target synchronization library.

[0072] Step S501 is necessary before the deadlock detection algorithm is executed. After step S501, the Go language includes the target synchronization library, synchronization library A, and other library files. These other library files, or applications written in Go, will call synchronization library A at runtime. For applications that need deadlock detection (which are Go programs), the target synchronization library is still called at runtime; that is, there is no need to modify the code in the Go language source code that references the target synchronization library. During application runtime, the target synchronization library is called, thereby triggering the deadlock detection algorithm within the target synchronization library to execute deadlock detection. The deadlock detection process includes subsequent steps S502-S510.

[0073] S502, in response to the first coroutine acquiring the first lock of the target synchronization library, acquires the lock information in the target synchronization library.

[0074] The target synchronization library records the following lock information: I. The first correspondence between the pointer to the currently used second lock and the coroutine column number of the second coroutine, where the second coroutine is the coroutine using the second lock.

[0075] II. The second correspondence between the pointer of the second lock, the coroutine column number of the second coroutine, and the stack information of the second coroutine.

[0076] Third, the correspondence between the pointer to the second lock, the coroutine column number of the second coroutine, and the order in which the second coroutine uses the second lock.

[0077] IV. The fourth correspondence between the coroutine sequence number of the second coroutine and the number of times the lock is used in the second coroutine.

[0078] S503, based on the first correspondence in the lock information, determine whether the first lock has been reused by the first coroutine. If not, proceed to step S504; if yes, proceed to step S510.

[0079] S504, based on the first correspondence in the lock information, determine the second lock used by the first coroutine, excluding the first lock. The second lock is any lock different from the first lock.

[0080] S505, based on the third correspondence in the lock information, determine the second coroutine currently using the first and second locks. The second coroutine is another coroutine different from the first coroutine.

[0081] S506, determine whether the order in which the first goroutine uses the first lock and the second lock is the same as the order in which the second goroutine uses the first lock and the second lock. If yes, proceed to step S507; otherwise, proceed to step S510.

[0082] S507, the first coroutine acquires the first lock and times the acquisition time of the first lock.

[0083] S508, determine whether the acquisition time of the first lock is greater than or equal to the preset time threshold; if not, proceed to step S509; if yes, proceed to step S510.

[0084] S509, the first coroutine acquires and locks the first lock, and updates the lock information in the target library file.

[0085] S510 determines that a deadlock has occurred in the first coroutine and outputs the deadlock information.

[0086] The deadlock information may include at least one of the following: deadlock cause, pointer to the first lock, coroutine column number of the first coroutine, and stack information of the first coroutine. The deadlock cause is determined based on deadlock detection. For example, if a deadlock is detected when the first coroutine reuses the first lock, the deadlock cause is the first coroutine's reuse of the first lock. If a deadlock is detected when multiple coroutines use the first lock in an incorrect order, the deadlock cause is the same. If a deadlock is detected when the time taken for the first coroutine to acquire the first lock is greater than or equal to a preset time threshold, the deadlock cause is a timeout in the first coroutine's acquisition of the first lock.

[0087] Optionally, if a deadlock is determined to have occurred, all programs can be forcibly stopped to prevent further uncontrollable errors.

[0088] In this embodiment, the methods for determining whether the first lock is reused by the first goroutine based on the lock information, and for determining whether the order in which the first goroutine and the second goroutine use the first lock and the second lock are the same, have been described in detail in the above embodiments and will not be repeated here.

[0089] As can be seen, by adopting the technical solution provided in this application, the synchronization library is pre-copied and renamed "Synchronization Library A" and added to the Go language. The code in the Go language source code that references the synchronization library from other libraries is modified to reference Synchronization Library A. Furthermore, a deadlock detection algorithm is added to the synchronization library to generate the target synchronization library. This allows Go applications to directly use the deadlock detection algorithm in the target synchronization library called during runtime for deadlock detection, achieving the desired deadlock detection effect without relying on third-party tools. Therefore, it can quickly and accurately detect both existing and potential deadlocks during program execution, avoiding the problem of some deadlocks (such as potential deadlocks) not being detected in time, thus preventing the program from running normally. This greatly improves the accuracy and efficiency of deadlock detection. Moreover, it does not require modification of the application's own code, making the deadlock detection method provided in this embodiment more widely applicable. That is, any Go application can use the deadlock detection algorithm in the synchronization library file for deadlock detection without modifying the program's source code. Furthermore, by outputting deadlock information after a deadlock is detected, technicians can promptly obtain relevant information about the deadlock situation and perform related maintenance based on the deadlock information.

[0090] In summary, specific embodiments of this subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing can be advantageous.

[0091] The above are the program deadlock detection methods provided in the embodiments of this application. Based on the same idea, the embodiments of this application also provide a program deadlock detection device.

[0092] Figure 6 This is a schematic block diagram of a program deadlock detection device according to an embodiment of this application, such as... Figure 6 As shown, the device includes: The acquisition module 61 is used to acquire lock information in the target library file in response to the first object acquiring the first lock of the target library file of the first programming language; Detection module 62 is used to detect whether the first object satisfies the preset deadlock condition corresponding to the first lock based on the lock information; the preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects, the order in which the multiple objects use the first lock is incorrect; the multiple objects include the first object; The determination module 63 is used to determine that the first object has deadlocked if the first object satisfies the preset deadlock condition.

[0093] In one embodiment, the lock information includes at least one of the following: The first correspondence between the lock identifier information of the currently used second lock and the object identifier information of the second object; the second object is the object using the second lock; The second correspondence between the lock identifier information of the second lock, the object identifier information of the second object, and the stack information of the second object; The third correspondence between the lock identifier information of the second lock, the object information of the second object, and the usage order information of the second object on the second lock; The fourth correspondence between the object identification information of the second object and the number of times the lock of the second object is used.

[0094] In one embodiment, when the detection module 62 detects whether the first object satisfies the preset deadlock condition corresponding to the first lock based on the lock information, it performs the following steps: Based on the lock information, it is detected whether the first lock has been reused by the first object; If the first lock is reused by the first object, it is determined that the first object satisfies the preset deadlock condition; If the first lock is not reused by the first object, check whether the order in which the multiple objects use the first lock is incorrect; if the order in which the multiple objects use the first lock is incorrect, determine that the first object meets the preset deadlock condition.

[0095] In one embodiment, the lock information includes the first correspondence; When the detection module 62 detects whether the first lock has been reused by the first object based on the lock information, it performs the following steps: If the first correspondence includes a correspondence between the lock identifier information of the first lock and the object identifier information of the first object, it is determined that the first lock is reused by the first object.

[0096] In one embodiment, the lock information includes the first correspondence and the third correspondence; When the detection module 62 detects whether there is an error in the order in which the multiple objects use the first lock, it performs the following steps: Based on the first correspondence, determine the third lock used by the first object, in addition to the first lock; Based on the third correspondence, it is determined whether there exists a third object that uses the first lock and the third lock; the third object is different from the first object. If the third object exists, then if the first usage order information and the second usage order information are different, it is determined that the usage order of the multiple objects on the first lock is incorrect; wherein, the first usage order information is used to characterize the usage order of the first object on the first lock and the third lock, and the second usage order information is used to characterize the usage order of the third object on the first lock and the third lock.

[0097] In one embodiment, the apparatus further includes: The second acquisition module is used to acquire the first lock if the first object does not meet the preset deadlock condition after detecting whether the first object meets the preset deadlock condition based on the lock information. The second determining module is used to determine the acquisition time of the first object for the first lock during the process of acquiring the first lock; The third determining module is used to determine that the first object has deadlocked if the acquisition duration is greater than or equal to a preset duration threshold.

[0098] In one embodiment, the apparatus further includes: An update module is used to update the lock information in response to the first object acquiring the first lock after the first lock is acquired.

[0099] In one embodiment, when updating the lock information, the update module performs at least one of the following steps: In the first correspondence, a correspondence is added between the lock identifier information of the first lock and the object identifier information of the first object; In the second correspondence, a correspondence is added between the lock identifier information of the first lock, the object identifier information of the first object, and the stack information of the first object; In the third correspondence, the usage order information of the first object to the first lock is updated; In the fourth correspondence, the lock usage count of the first object is updated.

[0100] In one embodiment, the apparatus further includes: The output module is configured to output deadlock information after determining that the first object has deadlocked; the deadlock information includes at least one of the following: deadlock cause, lock identifier information of the first lock, object identifier information of the first object, and stack information of the first object.

[0101] In one embodiment, the apparatus further includes: The substitution module is used to replace the first standard library file of the first programming language with the target library file before acquiring the lock information in the target library file in response to the first object acquiring the first lock of the target library file of the first programming language; the source code of the language corresponding to the target library file includes a deadlock detection algorithm; Add a module to add a second standard library file to the first programming language; the second standard library file and the first standard library file have the same file content.

[0102] The apparatus employing embodiments of this application, in response to a first object acquiring a first lock on a target library file of a first programming language, obtains lock information from the target library file and detects whether the first object meets a preset deadlock condition corresponding to the first lock based on the lock information. If the first object meets the preset deadlock condition, a deadlock is determined to have occurred in the first object. The preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects (including the first object); or when the order in which the multiple objects use the first lock is incorrect. It is evident that as long as the first object acquires the first lock on the target library file of the first programming language, a deadlock detection action is triggered. Therefore, it can quickly and accurately detect both existing and potential deadlocks during program execution, avoiding the problem that some deadlock situations (such as potential deadlocks) cannot be detected in time, thus preventing the program from running normally and greatly improving the accuracy and efficiency of deadlock detection. Furthermore, since the lock information is stored in the target library file, the source code of the language corresponding to the target library file can obtain the lock information and perform deadlock detection based on the lock information. Therefore, there is no need to integrate third-party tools into the program, thereby reducing the space overhead within the program.

[0103] Those skilled in the art will understand that Figure 6 The program deadlock detection device in the document can be used to implement the program deadlock detection method described above. The details of the method should be similar to those described in the previous section. To avoid being too complicated, they will not be repeated here.

[0104] Following the same line of thought, embodiments of this application also provide an electronic device, such as... Figure 7As shown. Electronic devices can vary considerably due to differences in configuration or performance, and may include one or more processors 701 and memory 702. Memory 702 may store one or more application programs or data. Memory 702 may be temporary or persistent storage. The application programs stored in memory 702 may include one or more modules (not shown), each module may include a series of computer-executable instructions for the electronic device. Furthermore, processor 701 may be configured to communicate with memory 702 and execute the series of computer-executable instructions in memory 702 on the electronic device. The electronic device may also include one or more power supplies 703, one or more wired or wireless network interfaces 704, one or more input / output interfaces 705, and one or more keyboards 706.

[0105] Specifically, in this embodiment, the electronic device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for use in the electronic device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: In response to the first object acquiring a first lock on a target library file of a first programming language, lock information is acquired in the target library file; Based on the lock information, it is detected whether the first object satisfies the preset deadlock condition corresponding to the first lock; the preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects, the order in which the multiple objects use the first lock is incorrect; the multiple objects include the first object. If the first object satisfies the preset deadlock condition, it is determined that the first object has deadlocked.

[0106] The technical solution of this application embodiment, in response to a first object acquiring a first lock on a target library file of a first programming language, obtains lock information from the target library file and checks whether the first object meets the preset deadlock condition corresponding to the first lock based on the lock information. If the first object meets the preset deadlock condition, it is determined that the first object has deadlocked. The preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects (including the first object); or when the order in which multiple objects use the first lock is incorrect. It is evident that as long as the first object acquires the first lock on the target library file of the first programming language, a deadlock detection action will be triggered. Therefore, it is possible to quickly and accurately detect both existing and potential deadlocks during program execution, avoiding the problem that some deadlock situations (such as potential deadlocks) cannot be detected in time, thus preventing the program from running normally and greatly improving the accuracy and efficiency of deadlock detection. Furthermore, since the lock information is stored in the target library file, the source code of the language corresponding to the target library file can obtain the lock information and perform deadlock detection based on the lock information. Therefore, there is no need to integrate third-party tools into the program, thereby reducing the space overhead within the program.

[0107] This application also proposes a computer-readable storage medium that stores one or more computer programs, each computer program including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform various processes of the above-described program deadlock detection method embodiments, specifically for executing: In response to the first object acquiring a first lock on a target library file of a first programming language, lock information is acquired in the target library file; Based on the lock information, it is detected whether the first object satisfies the preset deadlock condition corresponding to the first lock; the preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects, the order in which the multiple objects use the first lock is incorrect; the multiple objects include the first object. If the first object satisfies the preset deadlock condition, it is determined that the first object has deadlocked.

[0108] The technical solution of this application embodiment, in response to a first object acquiring a first lock on a target library file of a first programming language, obtains lock information from the target library file and checks whether the first object meets the preset deadlock condition corresponding to the first lock based on the lock information. If the first object meets the preset deadlock condition, it is determined that the first object has deadlocked. The preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects (including the first object); or when the order in which multiple objects use the first lock is incorrect. It is evident that as long as the first object acquires the first lock on the target library file of the first programming language, a deadlock detection action will be triggered. Therefore, it is possible to quickly and accurately detect both existing and potential deadlocks during program execution, avoiding the problem that some deadlock situations (such as potential deadlocks) cannot be detected in time, thus preventing the program from running normally and greatly improving the accuracy and efficiency of deadlock detection. Furthermore, since the lock information is stored in the target library file, the source code of the language corresponding to the target library file can obtain the lock information and perform deadlock detection based on the lock information. Therefore, there is no need to integrate third-party tools into the program, thereby reducing the space overhead within the program.

[0109] This application provides a computer program product, including a computer program, which is executed by a processor to implement the various processes of the above-described program deadlock detection method embodiment and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0110] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0111] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0112] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0113] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0114] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0115] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0116] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0117] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0118] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0119] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0120] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0121] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0122] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for detecting program deadlock, characterized in that, include: In response to the first object acquiring a first lock on a target library file of a first programming language, lock information in the target library file is acquired; Based on the lock information, it is detected whether the first object satisfies the preset deadlock condition corresponding to the first lock; the preset deadlock condition includes at least one of the following: whether the first lock is reused by the first object; when the first lock is used by multiple objects, the order in which the multiple objects use the first lock is incorrect. The plurality of objects includes the first object; If the first object satisfies the preset deadlock condition, it is determined that the first object has deadlocked.

2. The method according to claim 1, characterized in that, The lock information includes at least one of the following: The first correspondence between the lock identifier information of the currently used second lock and the object identifier information of the second object; the second object is the object using the second lock; The second correspondence between the lock identifier information of the second lock, the object identifier information of the second object, and the stack information of the second object; The third correspondence between the lock identifier information of the second lock, the object information of the second object, and the usage order information of the second object on the second lock; The fourth correspondence between the object identification information of the second object and the number of times the lock of the second object is used.

3. The method according to claim 2, characterized in that, The step of detecting whether the first object satisfies the preset deadlock condition corresponding to the first lock based on the lock information includes: Based on the lock information, it is detected whether the first lock has been reused by the first object; If the first lock is reused by the first object, it is determined that the first object satisfies the preset deadlock condition; If the first lock is not reused by the first object, check whether the order in which the multiple objects use the first lock is incorrect; if the order in which the multiple objects use the first lock is incorrect, determine that the first object meets the preset deadlock condition.

4. The method according to claim 3, characterized in that, The lock information includes the first correspondence; The step of detecting whether the first lock has been reused by the first object based on the lock information includes: If the first correspondence includes a correspondence between the lock identifier information of the first lock and the object identifier information of the first object, it is determined that the first lock is reused by the first object.

5. The method according to claim 3, characterized in that, The lock information includes the first correspondence and the third correspondence; The step of detecting whether the order in which the plurality of objects use the first lock is incorrect includes: Based on the first correspondence, determine the third lock used by the first object, in addition to the first lock; Based on the third correspondence, it is determined whether there exists a third object that uses the first lock and the third lock; the third object is different from the first object. If the third object exists, then if the first usage order information and the second usage order information are different, it is determined that the usage order of the multiple objects on the first lock is incorrect; wherein, the first usage order information is used to characterize the usage order of the first object on the first lock and the third lock, and the second usage order information is used to characterize the usage order of the third object on the first lock and the third lock.

6. The method according to claim 2, characterized in that, After detecting whether the first object satisfies the preset deadlock condition corresponding to the first lock based on the lock information, the method further includes: If the first object does not meet the preset deadlock condition, acquire the first lock; During the process of acquiring the first lock, the duration of the first object's acquisition of the first lock is determined; If the acquisition duration is greater than or equal to a preset duration threshold, it is determined that the first object has deadlocked.

7. The method according to claim 6, characterized in that, After acquiring the first lock, the method further includes: In response to the first object acquiring the first lock, the lock information is updated.

8. The method according to claim 7, characterized in that, Updating the lock information includes at least one of the following: In the first correspondence, a correspondence is added between the lock identifier information of the first lock and the object identifier information of the first object; In the second correspondence, a correspondence is added between the lock identifier information of the first lock, the object identifier information of the first object, and the stack information of the first object; In the third correspondence, the usage order information of the first object to the first lock is updated; In the fourth correspondence, the lock usage count of the first object is updated.

9. The method according to claim 2, characterized in that, After determining that the first object has deadlocked, the method further includes: Output deadlock information; the deadlock information includes at least one of the following: deadlock cause, lock identifier information of the first lock, object identifier information of the first object, and stack information of the first object.

10. The method according to claim 1, characterized in that, Before acquiring the lock information in the target library file in response to the first object acquiring the first lock of the target library file of the first programming language, the method further includes: The target library file is used to replace the first standard library file of the first programming language; the source code of the language corresponding to the target library file includes a deadlock detection algorithm. Add a second standard library file to the first programming language; the second standard library file and the first standard library file have the same file content.

11. A program deadlock detection device, characterized in that, include: The acquisition module is configured to acquire lock information in the target library file in response to the first object acquiring a first lock of the target library file of the first programming language; The detection module is used to detect whether the first object satisfies the preset deadlock condition corresponding to the first lock based on the lock information; the preset deadlock condition includes at least one of the following: whether the first lock is used repeatedly by the first object; when the first lock is used by multiple objects, the order in which the multiple objects use the first lock is incorrect; The plurality of objects includes the first object; The determination module is used to determine that the first object has deadlocked if the first object satisfies the preset deadlock condition.

12. An electronic device, characterized in that, The device includes a processor and a memory electrically connected to the processor, the memory storing a computer program, and the processor being configured to call and execute the computer program from the memory to implement the program deadlock detection method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The storage medium is used to store a computer program that can be executed by a processor to implement the program deadlock detection method as described in any one of claims 1-10.

14. A computer program product, characterized in that, Includes a computer program, which is executed by a processor to implement the program deadlock detection method as described in any one of claims 1-10.

Images