CN113886096A - 一种死锁的定位方法 - Google Patents

一种死锁的定位方法 Download PDF

Info

Publication number
CN113886096A
CN113886096A CN202111027440.2A CN202111027440A CN113886096A CN 113886096 A CN113886096 A CN 113886096A CN 202111027440 A CN202111027440 A CN 202111027440A CN 113886096 A CN113886096 A CN 113886096A
Authority
CN
China
Prior art keywords
deadlock
gdb
log file
locking
debugging
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111027440.2A
Other languages
English (en)
Inventor
何俭飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Hongji Information Technology Co Ltd
Original Assignee
Shanghai Hongji Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Hongji Information Technology Co Ltd filed Critical Shanghai Hongji Information Technology Co Ltd
Priority to CN202111027440.2A priority Critical patent/CN113886096A/zh
Publication of CN113886096A publication Critical patent/CN113886096A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/524—Deadlock detection or avoidance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/366—Software debugging using diagnostics

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种死锁的定位方法，包括以下步骤：使用调试器gdb拉起会产生死锁的进程；在加锁、解锁操作上设置断点；记录调试器的输出到log文件；运行被拉起的进程：运行期间会触发断点，在自动化脚本的控制下，记录调试信息到日志文件中；死锁产生，使用文本处理工具分析log文件；进程运行一段时间后，触发死锁条件，此时gdb卡主不动，观察到此现象，退出gdb，使用Linux下的文本处理工具分析记录的日志文件；定位死锁原因：通过文本处理工具分析日志文件，迅速定位出产生死锁的原因。本发明可以在死锁发生时，迅速定位死锁产生的原因，提高问题处理效率。

Description

一种死锁的定位方法
技术领域
本发明涉及通信技术领域，具体是指一种死锁的定位方法。
背景技术
在进行应用程序编程时，对于共享数据的访问，经常采用锁机制来保证各个使用者之间的互斥与同步。其中常用的锁有自旋锁、互斥锁、读写锁。以互斥锁为例，修改变量A时，先进行加锁，此时别人只能等待前一个锁持有者释放了锁资源才能对A进行访问(读取或者修改)，否则就一直等待。一旦前者没有释放锁资源，则后者只能一直尝试去获取并等待，这种现象就叫做死锁，其会导致进程卡住不动，无法响应外部操作，无法进行业务处理。
目前稍成规模的软件系统中，锁机制是不可避免要使用的，但是死锁问题的发生会严重影响系统的运行。故而在进行编程时，一方面要尽量避免使用锁，另一方面需要严格处理与锁有关的逻辑，避免死锁的发生。
当前情况下，一旦发生死锁，基本上都是靠开发人员进行代码梳理，分析锁的使用逻辑，从而定位死锁产生的原因，这种方法非常耗时，因为锁的使用一般情况下会分布在多处逻辑中，需要一个个进行分析，最终才能确认原因。
所以，一种定位、分析应用程序产生死锁原因的方法成为人们亟待解决的问题。
发明内容
本发明的目的是借助调试工具(gdb)和文本处理工具记录下进程中的加锁、解锁操作，一旦发生死锁，通过分析记录下的log文件，可以迅速定位死锁产生的原因，不用开发人员在多处逻辑中进行分析、演绎。
为实现上述目的，本发明提供的技术方案为：一种死锁的定位方法，包括以下步骤：
步骤1、使用调试器gdb拉起会产生死锁的进程：通过gdb来控制进程的运行情况，同时对其加以调试、分析；
步骤2、在加锁、解锁操作上设置断点；
步骤3、记录调试器的输出到log文件；
步骤4、运行被拉起的进程：运行期间会触发断点，在自动化脚本的控制下，记录调试信息到日志文件中；
步骤5、死锁产生，使用文本处理工具分析log文件；进程运行一段时间后，触发死锁条件，此时gdb卡主不动，观察到此现象，退出gdb，使用Linux下的文本处理工具分析记录的日志文件；
步骤6、定位死锁原因：通过文本处理工具分析日志文件，迅速定位出产生死锁的原因；
定位原理：加锁、解锁操作必须成对出现且相邻，一旦没有成对出现且相邻，就意味着有加锁但是没有解锁，这样其他加锁就无法成功，从而产生死锁。
作为改进，所述gdb为Linux系统下的应用调试器。
作为改进，所述步骤2中在加锁、解锁操作上设置断点用于在gdb中运行进程时，保证进程运行到加锁、解锁操作的特定代码时，就会在断点处停下。
作为改进，所述步骤3中调试器的调试采用自动化调试，在调试前将需要调试的步骤写成自动化的脚本，让其自动执行，且记录执行过程中的输出信息。
作为改进，所述文本处理工具包括cat、grep、sed。
本发明与现有技术相比的优点在于：本发明可以在死锁发生时，迅速定位死锁产生的原因，提高问题处理效率。
具体实施方式
下面对本发明一种死锁的定位方法做进一步的详细说明。
一种死锁的定位方法，包括以下步骤：
步骤1、使用调试器gdb拉起会产生死锁的进程：所述gdb为Linux下的应用调试器，通过gdb来控制进程的运行情况，同时对其加以调试、分析；
步骤2、在加锁、解锁操作上设置断点：在gdb中运行进程时，可以在希望进程暂停的地方打上断点，这样进程一旦运行到特定代码时，就会在断点处停下，便于观察、分析；此处要探究进程的死锁问题，故而将断点设置在加锁、解锁操作上；
步骤3、记录调试器的输出到log文件：处理器运行进程时的速度非常快，其时间单位为纳秒级别，在gdb中手动一步步单步调试不利于观察分析，故而将需要调试的步骤写成自动化的脚本，让其自动执行，且记录执行过程中的输出信息；
步骤4、运行被拉起的进程：步骤1-3只是在gdb中的准备工作，进程还未被运行起来，当准备工作完成，就可以真正拉起进程，使其运行；进程运行期间会触发断点，在自动化脚本的控制下，记录调试信息到日志文件中；
步骤5、死锁产生，使用文本处理工具分析log文件；进程运行一段时间后，触发死锁条件，此时gdb卡主不动，观察到此现象，退出gdb，使用Linux下的文本处理工具cat、grep、sed等分析记录的日志文件；
步骤6、定位死锁原因：通过文本处理工具分析日志文件，迅速定位出产生死锁的原因；
定位原理：加锁、解锁操作必须成对出现且相邻，一旦没有成对出现且相邻，就意味着有加锁但是没有解锁，这样其他加锁就无法成功，从而产生死锁。
本发明一种死锁的定位方法的具体实施过程如下：
1)准备示例程序：mutex_lock_test.c(不含行号)；
Figure BDA0003244089030000031
Figure BDA0003244089030000041
2)编译上述程序：产生可执行文件mutex_lock_test：
gcc-g3-O0-o mutex_lock_test mutex_lock_test.c–lpthread
3)准备调试器脚本：gdb_debug.cmd(不含行号)；
Figure BDA0003244089030000042
Figure BDA0003244089030000051
4)调试器拉起上述可执行程序：
gdb mutex_lock_test-x gdb_debug.cmd
5)死锁发生，使用“Ctrl+C”终止程序执行，产生log文件gdb_debug.log
6)分析log文件：
cat gdb_debug.log|grep-A1"^#0.*pthread_mutex_"|sed"s/from.*$//g"|sed"s/.*in//g"|nl
7)输出解释：
1 pthread_mutex_lock()
2 _dl_addr()
3 --
4 pthread_mutex_unlock()
5 _dl_addr()
6 --
7 pthread_mutex_lock()
8 simulate_thread_A(data＝0x0)at mutex_lock_test.c:11
9 --
10 pthread_mutex_unlock()
11 simulate_thread_A(data＝0x0)at mutex_lock_test.c:13
12 --
13 pthread_mutex_lock()
14 simulate_thread_A(data＝0x0)at mutex_lock_test.c:11
15 --
16 pthread_mutex_unlock()
17 simulate_thread_A(data＝0x0)at mutex_lock_test.c:13
18 --
19 pthread_mutex_lock()
20 simulate_thread_A(data＝0x0)at mutex_lock_test.c:11
21 --
22 pthread_mutex_unlock()
23 simulate_thread_A(data＝0x0)at mutex_lock_test.c:13
24 --
25 pthread_mutex_lock()
26 simulate_thread_B(data＝0x0)at mutex_lock_test.c:25
27 --
28 pthread_mutex_lock()
29 simulate_thread_A(data＝0x0)at mutex_lock_test.c:11
30 --
31 pthread_mutex_lock()
32 simulate_thread_B(data＝0x0)at mutex_lock_test.c:25
从输出解释中可以看出：
1、4行：不是真正加锁、解锁操作，不用在意；
7、10：线程A第一次进行加锁、解锁；锁操作成对出现，没有问题；
13、16：线程A第二次进行加锁、解锁；锁操作成对出现，没有问题；
19、22：线程A第三次进行加锁、解锁；锁操作成对出现，没有问题；
25：线程B第一次加锁；
28：线程A第四次加锁；
32：线程B第二次加锁；
从上述分析可以看出：死锁发生在日志中的28行和32行，对应代码中的11行和25行，原因为线程B加锁后，没有进行释放，线程A尝试去加锁，无法加锁成功(此时已经死锁)，线程B第二次尝试去加锁，无法加锁成功。
以上对本发明及其实施方式进行了描述，上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，如果本领域的普通技术人员受其启示，在不脱离本发明创造宗旨的情况下，不经创造性的设计出与该技术方案相似的结构方式及实施例，均应属于本发明的保护范围。

Claims (5)

1.一种死锁的定位方法，其特征在于：包括以下步骤：
步骤1、使用调试器gdb拉起会产生死锁的进程：通过gdb来控制进程的运行情况，同时对其加以调试、分析；
步骤2、在加锁、解锁操作上设置断点；
步骤3、记录调试器的输出到log文件；
步骤4、运行被拉起的进程：运行期间会触发断点，在自动化脚本的控制下，记录调试信息到日志文件中；
步骤5、死锁产生，使用文本处理工具分析log文件；进程运行一段时间后，触发死锁条件，此时gdb卡主不动，观察到此现象，退出gdb，使用Linux下的文本处理工具分析记录的日志文件；
步骤6、定位死锁原因：通过文本处理工具分析日志文件，迅速定位出产生死锁的原因；
定位原理：加锁、解锁操作必须成对出现且相邻，一旦没有成对出现且相邻，就意味着有加锁但是没有解锁，这样其他加锁就无法成功，从而产生死锁。
2.根据权利要求1所述的一种死锁的定位方法，其特征在于：所述gdb为Linux系统下的应用调试器。
3.根据权利要求1所述的一种死锁的定位方法，其特征在于：所述步骤2中在加锁、解锁操作上设置断点用于在gdb中运行进程时，保证进程运行到加锁、解锁操作的特定代码时，就会在断点处停下。
4.根据权利要求1所述的一种死锁的定位方法，其特征在于：所述步骤3中调试器的调试采用自动化调试，在调试前将需要调试的步骤写成自动化的脚本，让其自动执行，且记录执行过程中的输出信息。
5.根据权利要求1所述的一种死锁的定位方法，其特征在于：所述文本处理工具包括cat、grep、sed。
CN202111027440.2A 2021-09-02 2021-09-02 一种死锁的定位方法 Pending CN113886096A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111027440.2A CN113886096A (zh) 2021-09-02 2021-09-02 一种死锁的定位方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111027440.2A CN113886096A (zh) 2021-09-02 2021-09-02 一种死锁的定位方法

Publications (1)

Publication Number Publication Date
CN113886096A true CN113886096A (zh) 2022-01-04

Family

ID=79012042

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111027440.2A Pending CN113886096A (zh) 2021-09-02 2021-09-02 一种死锁的定位方法

Country Status (1)

Country Link
CN (1) CN113886096A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117873740A (zh) * 2024-03-12 2024-04-12 麒麟软件有限公司 基于gdb的进程死锁关系图构建方法、装置及存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117873740A (zh) * 2024-03-12 2024-04-12 麒麟软件有限公司 基于gdb的进程死锁关系图构建方法、装置及存储介质
CN117873740B (zh) * 2024-03-12 2024-06-07 麒麟软件有限公司 基于gdb的进程死锁关系图构建方法、装置及存储介质

Similar Documents

Publication Publication Date Title
Edelstein et al. Framework for testing multi‐threaded Java programs
Musuvathi et al. Finding and Reproducing Heisenbugs in Concurrent Programs.
Gluck et al. Using SPIN model checking for flight software verification
Thane et al. Using deterministic replay for debugging of distributed real-time systems
Soltani et al. A guided genetic algorithm for automated crash reproduction
US20080127117A1 (en) Method and apparatus for instrumentation in a multiprocessing environment
US20040093180A1 (en) Auto-scheduling of tests
US6978444B1 (en) Computer-implemented method and system for automatically invoking a predetermined debugger command at a desired location of a single thread of a program
CN110059014B (zh) 一种并发程序数据竞争指令级定位方法
CN107577593A (zh) 使用执行单一步骤来诊断编码
Shibanai et al. Actoverse: a reversible debugger for actors
WO2011084535A2 (en) Establishing a useful debugging state for a multithreaded computer program
US20110271284A1 (en) Method of Simulating, Testing, and Debugging Concurrent Software Applications
CN113886096A (zh) 一种死锁的定位方法
US8381185B2 (en) Apparatus, system, and method for dynamic module flow analysis
Pacheco Postmortem debugging in dynamic environments
Bechini et al. Design of a toolset for dynamic analysis of concurrent Java programs
CN108021495B (zh) 基于回放的代码调试方法
Ponamgi et al. Debugging multithreaded programs with MPD
Yuan et al. Raproducer: Efficiently diagnose and reproduce data race bugs for binaries via trace analysis
Lauwaerts et al. Event-Based Out-of-Place Debugging
Kasikci et al. Failure sketches: A better way to debug
Dovgalyuk et al. Don't panic: reverse debugging of kernel drivers
Long et al. Checking linearizability with fine-grained traces
Appelbe et al. Integrating tools for debugging and developing multitasking programs

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination