CN107479980B

CN107479980B - Method and equipment for detecting deadlock in application

Info

Publication number: CN107479980B
Application number: CN201610402975.6A
Authority: CN
Inventors: 赵树起
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2016-06-08
Filing date: 2016-06-08
Publication date: 2021-02-12
Anticipated expiration: 2036-06-08
Also published as: CN107479980A

Abstract

The application aims to provide a method and equipment for detecting deadlock in an application. Compared with the prior art, the method and the device have the advantages that lock tracking configuration operation is performed on the target application, a plurality of pieces of lock operation information during the running period of the target application are obtained, and whether deadlock exists in the target application or not is determined by detecting the plurality of pieces of lock operation information; according to the method, the tracking of any lock operation is completed by dynamically modifying the application program execution code, the user-defined lock operation can be tracked, and then whether the deadlock exists or not is determined according to the lock operation tracking result, so that the deadlock problem is accurately and efficiently detected, and the user experience is improved. In addition, the potential deadlock condition comprises that when coroutine tasks are switched in the same physical thread, the coroutine tasks before switching have unreleased locks, and therefore detection of deadlock problems in the coroutine is supported.

Description

Method and equipment for detecting deadlock in application

Technical Field

The present application relates to the field of computers, and in particular, to a technique for detecting deadlock in an application.

Background

Unlike typical single-threaded application development, multi-threaded program development needs to consider more problems, such as common potential inter-thread interaction problems. For the resource concurrently accessed by multiple threads, if the resource is not protected by mutual exclusion operation, the problem of competition conflict can occur, the multiple threads can cause the exception of the application program due to mutual influence, and the running result is unreliable. To this end, resource locks are used to address such problems. However, in a multi-thread application program, because of the problem of the use method of the lock or the multi-lock locking sequence, the application program may be deadlocked, so that the thread is suspended, and the program cannot run normally.

Deadlock is one of the most difficult problems to investigate in a multi-thread program, many deadlock problems can not be found even in a development and test stage, and cannot be triggered in some scenarios until a product is on line, and the occurrence of the deadlock problem is fatal to services with high real-time requirements. To address this type of problem, a number of methods have been explored, but because of the complexity of the cause of the deadlock, no general method has found all deadlock problems. The following lists common deadlock detection methods/tools as follows:

1) the method for scanning the software source code to perform static analysis comprises the following steps: the Cqual/Oink/Jqual is an open-source static language analysis tool, the technology comprehensively adopts type inference and constraint solving, and the deadlock detection problem can be well completed; clang provides a-Wthread-safety compiling switch, whether codes meet the specifications described in the annotations can be statically detected according to the code annotation information, and Desley Hutchins and the like provide deadlock detection extension for thread-safety inspection.

2) The method for tracking the lock use method and dynamically analyzing the application program during operation comprises the following steps: valgrind is a collection of emulated debugging tools for open source code (GPL V2) under Linux. Helgrind is a tool used for dynamically detecting the inter-process concurrent errors in the valgrind and supports programming languages such as C/C + +/Fortran. Helgrind can detect three POSIX pthreads use problems: lock type misuse, deadlock caused by wrong locking sequence and data access concurrency conflict.

3) The method combining static analysis and dynamic verification comprises the following steps: and (4) discovering potential deadlock problems by using static analysis, and then constructing a trigger scene in the running of the application program to confirm the existence of the deadlock problems.

Because of the complexity of program syntax, static analysis tools are generally unable to directly determine important issues of a program. The uncertainty of static analysis tools indicates that it is difficult for any automated static analysis tool to reliably and completely determine whether a program actually has a problem while running. The practicability of the tool is seriously influenced by too high false alarm, the precision of a certain program is sacrificed in order to reduce the false alarm rate, so that the false alarm and the false alarm are generated, and finally, the static analysis tool faces the serious false alarm rate, the false alarm rate and the repeated alarm rate.

The dynamic detection method is to detect the defects in the software by executing the test program through the test cases or adding real application scenes under the condition of running the tested program, the detection result has the advantage of low false alarm rate, however, the dynamic execution time is long, and if a satisfactory coverage result needs to be achieved, a very complete test case set is needed, so the dynamic detection has the disadvantages of low detection efficiency and high false alarm rate.

In addition, it is more important that the common static and dynamic detection methods only provide support for system-specific thread mutual exclusion primitives, such as support for pthread operation under unix/linux, support for critical section operation under windows, and the like. However, many current applications such as tcmalloc implement user-mode locks, and these general solutions cannot be found if deadlock occurs in user-defined lock operations.

Disclosure of Invention

An object of the present application is to provide a method and an apparatus for detecting deadlock in an application, so as to solve the problem of accurately and efficiently detecting deadlock.

According to an aspect of the present application, there is provided a method for detecting deadlock in an application, wherein the method comprises:

executing lock tracking configuration operation on the target application;

acquiring a plurality of pieces of lock operation information during the running period of the target application;

determining whether a deadlock exists in the target application by detecting the plurality of lock operation information.

According to another aspect of the present application, there is also provided an apparatus for detecting deadlock in an application, wherein the apparatus includes:

the configuration device is used for executing lock tracking configuration operation on the target application;

the acquisition device is used for acquiring a plurality of pieces of lock operation information during the running period of the target application;

detecting means for determining whether a deadlock exists in the target application by detecting the plurality of lock operation information.

According to yet another aspect of the present application, there is also provided an application for detecting deadlock, wherein the application comprises the apparatus as described above.

Compared with the prior art, the method and the device have the advantages that lock tracking configuration operation is performed on the target application, a plurality of pieces of lock operation information during the running period of the target application are obtained, and whether deadlock exists in the target application or not is determined by detecting the plurality of pieces of lock operation information; according to the method, the tracking of any lock operation is completed by dynamically modifying the application program execution code, the user-defined lock operation can be tracked, and then whether the deadlock exists or not is determined according to the lock operation tracking result, so that the deadlock problem is accurately and efficiently detected, and the user experience is improved. In addition, the potential deadlock condition comprises that when coroutine tasks are switched in the same physical thread, the coroutine tasks before switching have unreleased locks, and therefore detection of deadlock problems in the coroutine is supported.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:

FIG. 1 illustrates a flow diagram of a method of detecting deadlock in an application, in accordance with an aspect of the subject application;

FIG. 2 illustrates a lock dependency topology according to one embodiment of the present application;

FIG. 3 illustrates a schematic diagram of an apparatus for detecting deadlock in an application, according to another aspect of the subject application.

The same or similar reference numbers in the drawings identify the same or similar elements.

Detailed Description

The present application is described in further detail below with reference to the attached figures.

In a typical configuration of the present application, the terminal, the device serving the network, and the trusted party each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-transitory computer readable media (transient media), such as modulated data signals and carrier waves.

An application for detecting deadlocks is provided, wherein the application comprises a device 1. For example, the device 1 may be a deadlock detection library. The device 1 may track lock operations (including user-defined lock operations) that are of interest to the user and perform lock collision detection based on the recorded lock operation information.

Preferably, the device 1 is added to the application by means of a static link or a dynamic link.

For example, a user may link the device 1 into an application at compile time; for applications with dynamic links, the user may also inject the device 1 directly into the application at runtime by way of injection. Specifically, a malloc (application for specifying a byte of memory) or open (opening and creating a file) encapsulation method may be implemented in the device 1, so as to ensure that the device 1 can execute the initialization code in the device 1 when the application is running at the beginning. And the link sequence of the device 1 is placed in front of libc (C function library) during static link and dynamic link; for an application program of the dynamic link libc, the device 1 can be injected into the application program by an injection mode of LD _ PRELOAD environment variable and the like, so that the deadlock detection function of the device 1 can be directly used without recompiling the application program.

Fig. 1 shows a flowchart of a method for detecting deadlock in an application according to an aspect of the present application, the method comprising step S11, step S12 and step S13.

First, in step S11, device 1 performs a lock tracking configuration operation on the target application.

In a specific embodiment, each lock call operation can be tracked through a series of configuration operations by tracking a function to be tracked, and a plurality of lock operation information can be acquired.

Preferably, in step S11, the device 1 acquires entry address information of a function to be tracked in the target application; backing up an instruction set which is larger than or equal to a preset length from the entry address information of the function to be tracked to a target address; modifying a first instruction starting from entry address information of the function to be tracked into a migration instruction with a preset length, wherein a destination address of the migration instruction is the target address; adding additional instructions to the set of instructions at the target address.

For example, after the target application is started, after the device 1 is loaded, an initialization operation is executed, the initialization function first collects information of functions to be tracked in the target application, then queries an entry address of each function to be tracked through application program symbol table information, and creates one or more new executable memory areas (sections) by using mmap (mapping a file or other objects into a memory) according to the address information, where the address space distance between the first address of the new memory areas and the entry address of one or more functions to be tracked is within 2 GB.

More preferably, in step S11, the device 1 dynamically disassembles an instruction set of a predetermined length starting from entry address information of the function to be traced to determine a full length of the instruction set, wherein the full length is greater than or equal to the predetermined length; backing up the full length of the instruction set to a target address.

For example, in the above example, the predetermined length is set to 5 bytes. For the entry address of any function to be tracked, dynamically disassembling an instruction set containing the first 5 bytes from the entry address, determining the complete length of the instruction set, copying the instructions to a new memory area created by mmap if the instructions are all position-independent instructions, and copying the new instructions to the new memory area after repairing the position offset information of the instructions if the instructions are position-dependent instructions, so as to ensure that the instruction sets corresponding to the first 5 bytes of the entry address of all functions to be tracked complete backup.

More preferably, in step S11, if there is an instruction in the instruction set that includes location offset information, the device 1 modifies the location offset information accordingly before backing up the instruction set to the target address.

For example, as described above, if an operation of the function to be traced accesses a global variable or a static variable whose address is calculated based on the current instruction address plus an offset, if the instruction is simply transferred to a new address, the accessed address is a wrong address, which may cause an application exception. For this case, the position offset information within the assembler instruction is modified accordingly.

Then, the device 1 creates a child process for (creating a process almost identical to the original process), and the parent process waits for the child process to complete, and the child process inherits the memory image of the parent process and stores complete memory information. The child process modifies the first instruction of the entry address of each function to be tracked into an E9cd opcode (jmpq addr) with 5 bytes by calling ptrace (a parent process can control the child process to run) according to the list of the entry addresses of all the functions to be tracked, wherein E9 is machine code for encoding jmpq, cd is offset between the entry address of the function to be tracked and the migration destination address, opcode represents an operation code, the operation code is the jmpq addr, jmpq is a jmp (unconditional transfer) instruction, and q represents a jump to a 64-bit address. After the setting is successful, the child process finishes ptrace exit, the parent process finds that the child process completes continuous execution, but then all operations for calling the function to be tracked jump to a migration destination address (namely the target address) for execution, and therefore the opportunity is provided for lock call tracking.

In order to complete the tracking of the lock call, the present application adds an additional instruction in the instruction set located at the target address, and actually jumps to the content of the target address, which is an instruction set corresponding to a pseudo code in the following table:

migrated original instruction
	JMP returns the next instruction of the migrated instruction set
save parameter list
	prepare parameter list as before
callq migration instruction address
	test％rax,％rax
je record_lock_operation
	retq

TABLE 1

Wherein, the "next instruction of the migrated instruction set" is the first instruction of the entry address of the function to be tracked after the full length; "save parameter list" refers to the parameter list of the function to be tracked; "parameter list as before" refers to the content of the function parameter list to be tracked; the "callq migration instruction address" points to the address of the first instruction of the migrated instructions in the table; "test% rax,% rax" is used to judge whether the lock operation is successful, and the recording operation is successfully performed; recording a current lock operation event in the record _ lock _ operation; retq is the return instruction of the subroutine.

As mentioned above, the present application uses a method of dynamically modifying the execution code of an application to accomplish the tracking of any lock operation.

Next, in step S12, the device 1 acquires a plurality of pieces of lock operation information during the execution of the target application.

Preferably, the lock operation information includes at least any one of: locking operation information; attempting to lock the operation information; and unlocking operation information.

For example, the user may control the behavior of the device 1 through an environment variable, and the device 1 may accept the lock operation information through the environment variable; the locking operation information may include a locking function name/address list registering function name and lock variable parameter position in the function call, the locking operation attempting information may include a locking function name/address list registering function name and lock variable parameter position in the function call, and the unlocking operation information may include an unlocking function name/address list registering function name and lock variable parameter position in the function call.

Preferably, in step S12, the device 1 acquires a plurality of pieces of lock operation information during the running of the target application; and constructing a lock dependency topological graph corresponding to the target application according to the plurality of lock operation information.

For example, assume that the following operations exist in thread A: and locking the lock a, locking the lock b, unlocking the lock b, locking the lock c, unlocking the lock c, and unlocking the lock a, then constructing the lock dependence topological graph shown in fig. 2 according to the plurality of lock operation information.

Preferably, in step S12, for each piece of lock operation information, if the lock operation information is the first lock operation information of the Thread in the target application, the device 1 records the lock operation information in a Thread Local Storage (TLS) holding lock stack; otherwise, obtaining the last lock operation information from the thread local storage lock holding stack, adding a directed edge from the last lock operation information to the lock operation information in the lock dependency topological graph corresponding to the target application, and recording the lock operation information in the thread local storage lock holding stack.

For example, if the current operation is locking or an attempt to lock and a lock is successfully taken, (1) if the current lock is the first lock held by the thread, directly recording the current lock in the thread local storage lock stack; (2) otherwise, the last lock holding object is obtained from the thread local storage lock holding stack, a directed edge from the last lock to the lock is added in the lock dependence topological graph, and the lock is recorded in the thread local storage lock holding stack. And if the current operation is a lock releasing operation and the lock is successfully released, popping the lock object in the thread local storage lock stack.

Then, in step S13, the device 1 determines whether there is a deadlock in the target application by detecting the plurality of lock operation information.

Here, the plurality of lock operation information may include a plurality of lock operation information corresponding to a plurality of threads in the target application.

Preferably, in step S13, device 1 determines whether a deadlock exists in the target application by traversing the lock-dependent topology map.

For example, assume that thread 1 and thread 2 are included in the target application; the following operations exist in thread 1: locking the lock A, locking the lock B, locking the lock C, unlocking the lock B and unlocking the lock A; the following operations exist in thread 2: locking the lock C, locking the lock A, unlocking the lock A and unlocking the lock C; the lock dependency topological graph corresponding to the target application is A- > B- > C- > A, and the ring structure can be found by traversing the lock dependency topological graph, so that the target application is determined to have the deadlock.

Preferably, in step S13, the device 1 determines whether there is a deadlock in the target application by detecting whether there is a potential deadlock condition in the plurality of lock operation information.

For example, whether a deadlock exists in the target application may be determined by detecting multiple lock operation information within a thread or coroutine to determine whether a potential deadlock condition exists.

Here, coroutine is a program component, which has been widely used in C/C + + background development in recent years, and is generalized from the concept of a subroutine (procedure, function, routine, method, subroutine) that has only one entry point and returns only once, while coroutine allows multiple entry points, and can suspend and resume execution at a specified location. The C/C + + language native does not support coroutine, but there are many implementations that have completed this function, such as libtask library implemented by Russ Cox, boost. In order to complete the synchronization of the method in the coroutine, the coroutine framework needs to use user-mode coroutine locks, the operation of the locks cannot be detected by the existing deadlock detection tool, and the deadlock problem in the coroutine can be found by the method.

Preferably, the potential deadlock condition comprises at least any one of: a lock dependency ring exists in the plurality of lock operation information; when coroutine task switching occurs in the same physical thread, the coroutine task before switching has unreleased locks.

For example, the lock dependency ring may include a ring-shaped dependency relationship between the plurality of lock operation information, for example, if a ring structure exists in the lock dependency topology map, it indicates that a potential deadlock point exists. In addition, coroutines are realized as a user mode thread, context switching can occur in the execution of one task, namely, the execution right is handed to another coroutine task in the same physical thread, and therefore the utilization rate of the thread is fully improved. However, in practical use, it is found that because the coroutine of C/C + + is a non-native implementation, if a context switch occurs, mutual exclusion of lock operations cannot be guaranteed, for example, coroutine a and coroutine B both run in a physical thread X and need to perform some operations under the protection of a lock L, if coroutine a gives control over coroutine B while holding lock L, coroutine B waits for the lock being unable to be taken, and because coroutine B waits for the lock B being unable to give control over coroutine a, a deadlock is formed without a chance of releasing the lock. If, in step S12, device 1 finds that the coroutine task is switched to the physical thread, and the coroutine task before switching is not locked, device 1 may find a potential deadlock in step S13.

Preferably, the method further comprises: when the target application has a deadlock, the device 1 reports a trigger condition corresponding to the deadlock.

For example, the triggering condition of the deadlock may include a triggering path where the deadlock is possible. If a ring structure is found by traversing the lock-dependent topological graph in the running process of the target application, the potential deadlock problem is shown, and the path is a trigger path which can be used for deadlock. Here, deadlock detection results may be aggregated and reported to a user.

Fig. 3 shows an apparatus 1 for detecting deadlock in an application according to another aspect of the present application, wherein the apparatus 1 comprises configuration means 11, acquisition means 12 and detection means 13.

First, the configuration device 11 performs a lock tracking configuration operation on the target application.

Preferably, the configuration device 11 obtains entry address information of a function to be tracked in a target application; backing up an instruction set which is larger than or equal to a preset length from the entry address information of the function to be tracked to a target address; modifying a first instruction starting from entry address information of the function to be tracked into a migration instruction with a preset length, wherein a destination address of the migration instruction is the target address; adding additional instructions to the set of instructions at the target address.

More preferably, the configuration device 11 dynamically disassembles an instruction set of a predetermined length starting from the entry address information of the function to be traced to determine a full length of the instruction set, wherein the full length is greater than or equal to the predetermined length; backing up the full length of the instruction set to a target address.

More preferably, if there is an instruction in the instruction set that includes location offset information, the configuration apparatus 11 modifies the location offset information accordingly before backing up the instruction set to the target address.

TABLE 2

Then, the acquiring means 12 acquires a plurality of lock operation information during the running of the target application.

Preferably, the obtaining device 12 obtains a plurality of pieces of lock operation information during the running of the target application; and constructing a lock dependency topological graph corresponding to the target application according to the plurality of lock operation information.

Preferably, for each piece of lock operation information, if the lock operation information is the first lock operation information of the thread to which the target application belongs, the obtaining device 12 records the lock operation information in a thread local storage lock stack; otherwise, obtaining the last lock operation information from the thread local storage lock holding stack, adding a directed edge from the last lock operation information to the lock operation information in the lock dependency topological graph corresponding to the target application, and recording the lock operation information in the thread local storage lock holding stack.

Then, the detecting device 13 determines whether there is a deadlock in the target application by detecting the plurality of lock operation information.

Preferably, the detecting means 13 determines whether a deadlock exists in the target application by traversing the lock dependent topology map.

Preferably, the detecting means 13 determines whether a deadlock exists in the target application by detecting whether a potential deadlock condition exists in the plurality of lock operation information.

For example, the lock dependency ring may include a ring-shaped dependency relationship between the plurality of lock operation information, for example, if a ring structure exists in the lock dependency topology map, it indicates that a potential deadlock point exists. In addition, coroutines are realized as a user mode thread, context switching can occur in the execution of one task, namely, the execution right is handed to another coroutine task in the same physical thread, and therefore the utilization rate of the thread is fully improved. However, in practical use, it is found that because the coroutine of C/C + + is a non-native implementation, if a context switch occurs, mutual exclusion of lock operations cannot be guaranteed, for example, coroutine a and coroutine B both run in a physical thread X and need to perform some operations under the protection of a lock L, if coroutine a gives control over coroutine B while holding lock L, coroutine B waits for the lock being unable to be taken, and because coroutine B waits for the lock B being unable to give control over coroutine a, a deadlock is formed without a chance of releasing the lock. If the acquiring device 12 finds that the coroutine task is switched with the physical thread, and the coroutine task before switching has a lock and is not released, the detecting device 13 may find a potential deadlock.

Preferably, the device 1 further comprises reporting means (not shown in the figures); and when the target application has the deadlock, the reporting device reports the trigger condition corresponding to the deadlock.

It should be noted that the present application may be implemented in software and/or a combination of software and hardware, for example, implemented using Application Specific Integrated Circuits (ASICs), general purpose computers or any other similar hardware devices. In one embodiment, the software programs of the present application may be executed by a processor to implement the steps or functions described above. Likewise, the software programs (including associated data structures) of the present application may be stored in a computer readable recording medium, such as RAM memory, magnetic or optical drive or diskette and the like. Additionally, some of the steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.

In addition, some of the present application may be implemented as a computer program product, such as computer program instructions, which when executed by a computer, may invoke or provide methods and/or techniques in accordance with the present application through the operation of the computer. Program instructions which invoke the methods of the present application may be stored on a fixed or removable recording medium and/or transmitted via a data stream on a broadcast or other signal-bearing medium and/or stored within a working memory of a computer device operating in accordance with the program instructions. An embodiment according to the present application comprises an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to perform a method and/or a solution according to the aforementioned embodiments of the present application.

It will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is obvious that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. A plurality of units or means recited in the apparatus claims may also be implemented by one unit or means in software or hardware. The terms first, second, etc. are used to denote names, but not any particular order.

Claims

1. A method of detecting deadlock in an application, wherein the method comprises:

executing lock tracking configuration operation on the target application;

determining whether a deadlock exists in the target application by detecting the plurality of lock operation information;

wherein the performing the lock tracking configuration operation on the target application comprises:

acquiring entry address information of a function to be tracked in a target application;

backing up an instruction set which is larger than or equal to a preset length from the entry address information of the function to be tracked to a target address;

modifying a first instruction starting from entry address information of the function to be tracked into a migration instruction with a preset length, wherein a destination address of the migration instruction is the target address;

adding additional instructions to the set of instructions at the target address.

2. The method of claim 1, wherein the determining whether a deadlock exists in the target application by detecting the plurality of lock operation information comprises:

and determining whether the target application is deadlocked or not by detecting whether a potential deadlock condition exists in the plurality of pieces of lock operation information or not.

3. The method of claim 2, wherein the potential deadlock condition comprises at least any one of:

a lock dependency ring exists in the plurality of lock operation information;

when coroutine task switching occurs in the same physical thread, the coroutine task before switching has unreleased locks.

4. The method of claim 1, wherein the method further comprises:

and when the target application has the deadlock, reporting the trigger condition of the corresponding deadlock.

5. The method of claim 1, wherein the obtaining a plurality of lock operation information during the running of the target application comprises:

constructing a lock dependence topological graph corresponding to the target application according to the plurality of lock operation information;

wherein the determining whether a deadlock exists in the target application by detecting the plurality of lock operation information comprises:

determining whether a deadlock exists in the target application by traversing the lock-dependent topology graph.

6. The method of claim 5, wherein the constructing a lock dependency topology corresponding to the target application according to the plurality of lock operation information comprises:

for each piece of lock operation information, if the lock operation information is the first lock operation information of the thread to which the target application belongs, recording the lock operation information in a thread local storage; otherwise, obtaining the last lock operation information from the thread local storage lock holding stack, adding a directed edge from the last lock operation information to the lock operation information in the lock dependency topological graph corresponding to the target application, and recording the lock operation information in the thread local storage lock holding stack.

7. The method of claim 1, wherein the lock operation information comprises at least any one of:

locking operation information;

attempting to lock the operation information;

and unlocking operation information.

8. The method of claim 1, wherein the backing up a set of instructions greater than or equal to a predetermined length starting from entry address information of the function to be traced to a target address comprises:

dynamically disassembling an instruction set of a predetermined length starting from entry address information of the function to be traced to determine a full length of the instruction set, wherein the full length is greater than or equal to the predetermined length;

backing up the full length of the instruction set to a target address.

9. The method of claim 1, wherein the backing up a set of instructions greater than or equal to a predetermined length starting from entry address information of the function to be traced to a target address comprises:

if the instruction set comprises the position offset information, the position offset information is modified correspondingly before the instruction set is backed up to the target address.

10. An apparatus for detecting deadlock in an application, wherein the apparatus comprises:

detecting means for determining whether there is a deadlock in the target application by detecting the plurality of lock operation information;

wherein the configuration means is configured to:

11. The apparatus of claim 10, wherein the detection device is to:

12. The apparatus of claim 11, wherein the potential deadlock condition comprises at least any one of:

a lock dependency ring exists in the plurality of lock operation information;

13. The apparatus of claim 10, wherein the apparatus further comprises:

and the reporting device is used for reporting the trigger condition corresponding to the deadlock when the target application has the deadlock.

14. The apparatus of claim 10, wherein the obtaining means is configured to:

wherein the detection device is configured to:

15. The device of claim 14, wherein the constructing a lock dependency topology corresponding to the target application according to the plurality of lock operation information comprises:

for each piece of lock operation information, if the lock operation information is the first lock operation information of the thread which belongs to the target application, recording the lock operation information in a thread local storage lock stack; otherwise, obtaining the last lock operation information from the thread local storage lock holding stack, adding a directed edge from the last lock operation information to the lock operation information in the lock dependency topological graph corresponding to the target application, and recording the lock operation information in the thread local storage lock holding stack.

16. The apparatus of claim 10, wherein the lock operation information comprises at least any one of:

locking operation information;

attempting to lock the operation information;

and unlocking operation information.

17. The apparatus of claim 10, wherein the backing up a set of instructions greater than or equal to a predetermined length starting from entry address information of the function to be traced to a target address comprises:

backing up the full length of the instruction set to a target address.

18. The apparatus of claim 10, wherein the backing up a set of instructions greater than or equal to a predetermined length starting from entry address information of the function to be traced to a target address comprises:

19. A system for detecting deadlocks, wherein the system comprises an apparatus according to any of claims 10 to 18.

20. The system of claim 19, wherein the devices are added to the system through static links or dynamic links.