Linux 死锁工具,死锁现象及分析方法 之一 Linux C

最新推荐文章于 2022-12-25 13:58:04 发布
最新推荐文章于 2022-12-25 13:58:04 发布
阅读量398 收藏
点赞数
文章标签： Linux 死锁工具

1 什么是死锁

死锁 (DeadLock)： 是指两个或两个以上的进程(线程)在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程(线程)称为死锁进程(线程)。 由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程(线程)在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。

一种交叉持锁死锁的情形，此时执行程序中两个或多个线程发生永久堵塞(等待)，每个线程都在等待被其它线程占用并堵塞了的资源。例如，如果线程 1 锁住了记录 A 并等待记录 B，而线程 2 锁住了记录 B 并等待记录 A，这样两个线程就发生了死锁现象。在计算机系统中 , 如果系统的资源分配策略不当，更常见的可能是程序员写的程序有错误等，则会导致进程因竞争资源不当而产生死锁的现象。

2 产生死锁的四个必要条件

(1)互斥使用(资源独占)

一个资源每次只能给一个进程使用(比如写操作)

(2)占有且等待

进程在申请新的资源的同时，保持对原有资源的占有

(3)不可抢占

资源申请者不能强行从资源占有者手中夺取资源，资源只能由占有者自愿释放

(4)循环等待

P1等待P2占有的资源，P2等待P3的资源，...Pn等待P1的资源，形成一个进程等待回路

3 一个例子及图示

3.1 图示

3efe896fbabc

image.png

进程在执行一些代码之后，子线程 1 获得了锁 A，正试图获得锁 B，子线程 2 此时获得了锁 B，正试图获得锁 A，这样子线程 1 和子线程 2 将没有办法得到锁 A 和锁 B，因为它们各自被对方占有，永远不会释放，从而发生了死锁的现象。

3.2 代码

#include

#include

#include

pthread_mutex_t mutexA = PTHREAD_MUTEX_INITIALIZER;

pthread_mutex_t mutexB = PTHREAD_MUTEX_INITIALIZER;

pthread_mutex_t mutexC = PTHREAD_MUTEX_INITIALIZER;

static int counterA = 0;

static int counterB = 0;

int func1()

{

pthread_mutex_lock(&mutexA);

++counterA;

sleep(1);

pthread_mutex_lock(&mutexB);

++counterB;

pthread_mutex_unlock(&mutexB);

pthread_mutex_unlock(&mutexA);

return counterA;

}

int func2()

{

pthread_mutex_lock(&mutexB);

++counterB;

sleep(1);

pthread_mutex_lock(&mutexA);

++counterA;

pthread_mutex_unlock(&mutexA);

pthread_mutex_unlock(&mutexB);

return counterB;

}

void* start_routine1(void* arg)

{

while (1)

{

int iRetValue = func1();

if (iRetValue == 100000)

{

pthread_exit(NULL);

}

}

}

void* start_routine2(void* arg)

{

while (1)

{

int iRetValue = func2();

if (iRetValue == 100000)

{

pthread_exit(NULL);

}

}

}

void* start_routine(void* arg)

{

while (1)

{

sleep(1);

char szBuf[128];

memset(szBuf, 0, sizeof(szBuf));

strcpy(szBuf, (char*)arg);

}

}

int main()

{

pthread_t tid[4];

if (pthread_create(&tid[0], NULL, &start_routine1, NULL) != 0)

{

_exit(1);

}

if (pthread_create(&tid[1], NULL, &start_routine2, NULL) != 0)

{

_exit(1);

}

if (pthread_create(&tid[2], NULL, &start_routine, "thread3") != 0)

{

_exit(1);

}

if (pthread_create(&tid[3], NULL, &start_routine, "thread3") != 0)

{

_exit(1);

}

sleep(5);

//pthread_cancel(tid[0]);

pthread_join(tid[0], NULL);

pthread_join(tid[1], NULL);

pthread_join(tid[2], NULL);

pthread_join(tid[3], NULL);

pthread_mutex_destroy(&mutexA);

pthread_mutex_destroy(&mutexB);

pthread_mutex_destroy(&mutexC);

return 0;

}

3.3编译程序并执行

[hadoop@spark ~]$ gcc -g deadlock.c -o deadlock -lpthread

[hadoop@spark ~]$ ./deadlock

[hadoop@spark ~]$ ps -ef |grep -i deadlock

hadoop 103176 101848 0 15:42 pts/0 00:00:00 ./deadlock

4 使用 pstack 和 gdb 工具对死锁程序进行分析

4.1 pstack

第一次：

[hadoop@spark ~]$ pstack 103176

Thread 5 (Thread 0x7f3af34d2700 (LWP 103177)):

#0 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f3af389fdcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f3af389fc98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x00000000004008ee in func1 () at deadlock.c:18

#4 0x000000000040098b in start_routine1 (arg=0x0) at deadlock.c:43

#5 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f3af2cd1700 (LWP 103178)):

#0 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f3af389fdcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f3af389fc98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x000000000040094a in func2 () at deadlock.c:31

#4 0x00000000004009b9 in start_routine2 (arg=0x0) at deadlock.c:56

#5 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f3af24d0700 (LWP 103179)):

#0 0x00007f3af35921ad in nanosleep () from /lib64/libc.so.6

#1 0x00007f3af3592044 in sleep () from /lib64/libc.so.6

#2 0x00000000004009ed in start_routine (arg=0x400be0) at deadlock.c:69

#3 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#4 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f3af1ccf700 (LWP 103180)):

#0 0x00007f3af35921ad in nanosleep () from /lib64/libc.so.6

#1 0x00007f3af3592044 in sleep () from /lib64/libc.so.6

#2 0x00000000004009ed in start_routine (arg=0x400be0) at deadlock.c:69

#3 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#4 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f3af3cbd740 (LWP 103176)):

#0 0x00007f3af389ef57 in pthread_join () from /lib64/libpthread.so.0

#1 0x0000000000400aee in main () at deadlock.c:99

[hadoop@spark ~]$

第二次：

[hadoop@spark ~]$

[hadoop@spark ~]$ pstack 103176

Thread 5 (Thread 0x7f3af34d2700 (LWP 103177)):

#0 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f3af389fdcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f3af389fc98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x00000000004008ee in func1 () at deadlock.c:18

#4 0x000000000040098b in start_routine1 (arg=0x0) at deadlock.c:43

#5 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f3af2cd1700 (LWP 103178)):

#0 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f3af389fdcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f3af389fc98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x000000000040094a in func2 () at deadlock.c:31

#4 0x00000000004009b9 in start_routine2 (arg=0x0) at deadlock.c:56

#5 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f3af24d0700 (LWP 103179)):

#0 0x00007f3af35921ad in nanosleep () from /lib64/libc.so.6

#1 0x00007f3af3592044 in sleep () from /lib64/libc.so.6

#2 0x00000000004009ed in start_routine (arg=0x400be0) at deadlock.c:69

#3 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#4 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f3af1ccf700 (LWP 103180)):

#0 0x00007f3af35921ad in nanosleep () from /lib64/libc.so.6

#1 0x00007f3af3592044 in sleep () from /lib64/libc.so.6

#2 0x00000000004009ed in start_routine (arg=0x400be0) at deadlock.c:69

#3 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#4 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f3af3cbd740 (LWP 103176)):

#0 0x00007f3af389ef57 in pthread_join () from /lib64/libpthread.so.0

#1 0x0000000000400aee in main () at deadlock.c:99

[hadoop@spark ~]$

连续多次查看这个进程的函数调用关系堆栈, 死锁线程将一直处于等锁的状态，对比多次的函数调用堆栈输出结果，确定哪两个线程(或者几个线程)一直没有变化且一直处于等锁的状态。

分析：

根据上面的输出对比，线程 1 和线程 2 由第一次 pstack 输出的处在 sleep 函数变化为第二次 pstack 输出的处在 memset 函数。但是线程 4 和线程 5 一直处在等锁状态(pthread_mutex_lock)，在连续两次的 pstack 信息输出中没有变化，所以我们可以推测线程 4 和线程 5 发生了死锁。

然后通过 gdb attach 到死锁进程

[hadoop@spark ~]$ gdb attach 103176

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:

...

attach: No such file or directory.

Attaching to process 103176

Reading symbols from /home/hadoop/deadlock...done.

Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.

[New LWP 103180]

[New LWP 103179]

[New LWP 103178]

[New LWP 103177]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

Loaded symbols for /lib64/libpthread.so.0

Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.

Loaded symbols for /lib64/libc.so.6

Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.

Loaded symbols for /lib64/ld-linux-x86-64.so.2

0x00007f3af389ef57 in pthread_join () from /lib64/libpthread.so.0

Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7_4.2.x86_64

(gdb) info thread

Id Target Id Frame

5 Thread 0x7f3af34d2700 (LWP 103177) "deadlock" 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

4 Thread 0x7f3af2cd1700 (LWP 103178) "deadlock" 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

3 Thread 0x7f3af24d0700 (LWP 103179) "deadlock" 0x00007f3af35921ad in nanosleep () from /lib64/libc.so.6

2 Thread 0x7f3af1ccf700 (LWP 103180) "deadlock" 0x00007f3af35921ad in nanosleep () from /lib64/libc.so.6

* 1 Thread 0x7f3af3cbd740 (LWP 103176) "deadlock" 0x00007f3af389ef57 in pthread_join () from /lib64/libpthread.so.0

(gdb)

查看线程 4 和线程 5 的输出

(gdb) thread 5

[Switching to thread 5 (Thread 0x7f3af34d2700 (LWP 103177))]

#0 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

(gdb) where

#0 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f3af389fdcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f3af389fc98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x00000000004008ee in func1 () at deadlock.c:18

#4 0x000000000040098b in start_routine1 (arg=0x0) at deadlock.c:43

#5 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

(gdb) f 3

#3 0x00000000004008ee in func1 () at deadlock.c:18

18 pthread_mutex_lock(&mutexB);

(gdb) thread 4

[Switching to thread 4 (Thread 0x7f3af2cd1700 (LWP 103178))]

#0 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

(gdb) where

#0 0x00007f3af38a442d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f3af389fdcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f3af389fc98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x000000000040094a in func2 () at deadlock.c:31

#4 0x00000000004009b9 in start_routine2 (arg=0x0) at deadlock.c:56

#5 0x00007f3af389de25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f3af35cb34d in clone () from /lib64/libc.so.6

(gdb) f 3

#3 0x000000000040094a in func2 () at deadlock.c:31

31 pthread_mutex_lock(&mutexA);

(gdb) p mutexA

$1 = {__data = {__lock = 2, __count = 0, __owner = 103177, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},

__size = "\002\000\000\000\000\000\000\000\t\223\001\000\001", '\000' , __align = 2}

(gdb) p mutexB

$2 = {__data = {__lock = 2, __count = 0, __owner = 103178, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},

__size = "\002\000\000\000\000\000\000\000\n\223\001\000\001", '\000' , __align = 2}

(gdb) p mutexC

$3 = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},

__size = '\000' , __align = 0}

(gdb)

从上面可以发现，线程 4 正试图获得锁 mutexA，但是锁 mutexA 已经被 LWP 为 103177 的线程得到(__owner = 103177)，线程 5 正试图获得锁 mutexB，但是锁 mutexB 已经被 LWP 为 103178 的 得到(__owner = 103178)，从 pstack 的输出可以发现，LWP 103177 与线程 5 是对应的，LWP 103178 与线程 4 是对应的。所以我们可以得出， 线程 4 和线程 5 发生了交叉持锁的死锁现象。查看线程的源代码发现，线程 4 和线程 5 同时使用 mutexA 和 mutexB，且申请顺序不合理。

5 利用core文件分析

运行./deadlock(编译的时候加调试选项-g) 死锁阻塞

[hadoop@spark ~]$ ulimit -c unlimited

[hadoop@spark ~]$ ./deadlock

[hadoop@spark ~]$ ps -ef |grep deadlock

hadoop 33397 32933 0 08:49 pts/0 00:00:00 ./deadlock

hadoop 33472 102129 0 08:50 pts/2 00:00:00 grep --color=auto deadlock

[hadoop@spark ~]$ pstack 33397

Thread 5 (Thread 0x7f71f6f11700 (LWP 33398)):

#0 0x00007f71f72e342d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f71f72dedcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f71f72dec98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x00000000004008ee in func1 () at deadlock.c:18

#4 0x000000000040098b in start_routine1 (arg=0x0) at deadlock.c:43

#5 0x00007f71f72dce25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f71f700a34d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f71f6710700 (LWP 33399)):

#0 0x00007f71f72e342d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f71f72dedcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f71f72dec98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x000000000040094a in func2 () at deadlock.c:31

#4 0x00000000004009b9 in start_routine2 (arg=0x0) at deadlock.c:56

#5 0x00007f71f72dce25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f71f700a34d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f71f5f0f700 (LWP 33400)):

#0 0x00007f71f6fd11ad in nanosleep () from /lib64/libc.so.6

#1 0x00007f71f6fd1044 in sleep () from /lib64/libc.so.6

#2 0x00000000004009ed in start_routine (arg=0x400be0) at deadlock.c:69

#3 0x00007f71f72dce25 in start_thread () from /lib64/libpthread.so.0

#4 0x00007f71f700a34d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f71f570e700 (LWP 33401)):

#0 0x00007f71f6fd11ad in nanosleep () from /lib64/libc.so.6

#1 0x00007f71f6fd1044 in sleep () from /lib64/libc.so.6

#2 0x00000000004009ed in start_routine (arg=0x400be0) at deadlock.c:69

#3 0x00007f71f72dce25 in start_thread () from /lib64/libpthread.so.0

#4 0x00007f71f700a34d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f71f76fc740 (LWP 33397)):

#0 0x00007f71f72ddf57 in pthread_join () from /lib64/libpthread.so.0

#1 0x0000000000400aee in main () at deadlock.c:99

Ctrl+\ 产生core dump

[hadoop@spark ~]$ ./deadlock

^\Quit (core dumped)

[hadoop@spark ~]$ ls core.*

core.33397

[hadoop@spark ~]$ gdb deadlock core.33397

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:

...

Reading symbols from /home/hadoop/deadlock...done.

[New LWP 33397]

[New LWP 33398]

[New LWP 33399]

[New LWP 33400]

[New LWP 33401]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

Core was generated by `./deadlock'.

Program terminated with signal 3, Quit.

#0 0x00007f71f72ddf57 in pthread_join () from /lib64/libpthread.so.0

Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7_4.2.x86_64

(gdb) thread apply all bt

Thread 5 (Thread 0x7f71f570e700 (LWP 33401)):

#0 0x00007f71f6fd11ad in nanosleep () from /lib64/libc.so.6

#1 0x00007f71f6fd1044 in sleep () from /lib64/libc.so.6

#2 0x00000000004009ed in start_routine (arg=0x400be0) at deadlock.c:69

#3 0x00007f71f72dce25 in start_thread () from /lib64/libpthread.so.0

#4 0x00007f71f700a34d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f71f5f0f700 (LWP 33400)):

#0 0x00007f71f6fd11ad in nanosleep () from /lib64/libc.so.6

#1 0x00007f71f6fd1044 in sleep () from /lib64/libc.so.6

#2 0x00000000004009ed in start_routine (arg=0x400be0) at deadlock.c:69

#3 0x00007f71f72dce25 in start_thread () from /lib64/libpthread.so.0

#4 0x00007f71f700a34d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f71f6710700 (LWP 33399)):

#0 0x00007f71f72e342d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f71f72dedcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f71f72dec98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x000000000040094a in func2 () at deadlock.c:31

#4 0x00000000004009b9 in start_routine2 (arg=0x0) at deadlock.c:56

#5 0x00007f71f72dce25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f71f700a34d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f71f6f11700 (LWP 33398)):

#0 0x00007f71f72e342d in __lll_lock_wait () from /lib64/libpthread.so.0

#1 0x00007f71f72dedcb in _L_lock_812 () from /lib64/libpthread.so.0

#2 0x00007f71f72dec98 in pthread_mutex_lock () from /lib64/libpthread.so.0

#3 0x00000000004008ee in func1 () at deadlock.c:18

#4 0x000000000040098b in start_routine1 (arg=0x0) at deadlock.c:43

#5 0x00007f71f72dce25 in start_thread () from /lib64/libpthread.so.0

#6 0x00007f71f700a34d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f71f76fc740 (LWP 33397)):

#0 0x00007f71f72ddf57 in pthread_join () from /lib64/libpthread.so.0

#1 0x0000000000400aee in main () at deadlock.c:99

迪迪一下
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
c语言 deadlock
01-16
c语言 deadlock
DeadLock
weixin_33853827的博客
06-24 299
What causes the deadlock? I take “Generate SubAccountId” as example. <1> At last I find “ A TRIGGER tg_s_SAid_Add ON s_SAid FOR INSERT delay to commit transaction” leads to deadlock <2...
Deadlock --- 死锁
zxz414644665的专栏
11-04 742
A deadlock is a situation where an application locks up because two or more activities are waiting for each other to finish. 例子： using System; using System.Threading; public class Simple {
死锁的排查工具有哪些？
一瓶绿茶三元钱
05-23 614
死锁（Dead Lock）指的是两个或两个以上的运算单元（进程、线程或协程），都在等待对方释放资源，但没有一方提起释放资源，从而造成了一种阻塞的现象就称为死锁。 比如线程 1 拥有了锁 A 的情况下试图获取锁 B，而线程 2 又在拥有了锁 B 的情况下试图获取锁 A，这样双方就进入相互阻塞等待的情况，如下图所示： 死锁的代码实现如下： import java.util.concurrent.TimeUnit; public class DeadLockTest { public st
线程的死锁和Lock锁
lidong777777的博客
07-21 320
本次博客带领大家了解死锁的基本概念和死锁的四个条件，Lock锁的用法。
死锁与段错误解读分析
08-28
分析了linux程序员常遇到的死锁和段错误问题，从出现的原因到调试方法进行详细介绍。
操作系统实验六 死锁问题实验
05-14
通过本实验观察死锁产生的现象，考虑解决死锁问题的方法。从而进一步加深对于死锁问题的理解。掌握解决死锁问题的几种算法的编程和调试技术。练习怎样构造管程和条件变量，利用管程机制来避免死锁和饥俄问题的发生。
操作系统银行家算法避免死锁
06-17
银行家算法避免死锁 VM软件 Linux系统 C语言 成功编译 成功...（4）另选择一种死锁避免的方法进行实现，完成整个过程。如哲学家就餐、生产者-消费者或者读者-写者问题等。 （5）要求在linux ubuntu环境下使用c/c++编写
一种Linux内核自旋锁死锁检测机制的设计与实现.pdf
09-06
本文设计了一种自旋锁死锁检测机制，可以快速检测到 Linux 内核中的死锁，报告死锁相关信息供管理员分析使用。该机制可以帮助管理员快速检测到死锁的发生，并采取相应的措施来降低系统宕机时间，提高系统稳定性。 ...
gethostbyname_r在某些linux版本中多线程不安全问题.pdf
09-06
在 Linux 操作系统中，gethostbyname_r 函数是一个常用的 DNS 解析函数，但是，在某些 Linux 版本中，这个函数存在多线程不安全问题。本文将详细介绍这个问题，分析其原因，并提供解决方案。 问题描述： 在多线程...
死锁问题deadlock代码实现与解决
kcy的博客
04-26 370
涉及的相关命令 查看当前运行的进程： ps aux | grep 进程的名字 查看当前运行的轻量级进程（线程）：ps -aL | grep 进程的名字 查看当前主线程和新线程的关系: pstree -p 主线程id 进程栈的跟踪： pstack 进程pid gdb中执行涉及的命令 ！！！切记，gcc编译的时候一定要加上-g，否则无法使用gdb进行调试 查看线程： info threads 切换线程： thread 线程id 调试指定pid的进程： gdb attach pid 只运行当前线程: set
gdb定位死锁问题
strut的博客
09-15 1335
本案例借着gdb调试死锁的问题，演示在多线程场景下如何使用gdb调试多线程死锁的 调试过程： 1.为了重现死锁现象，自己写了个死锁demo [root@localhost bin]# ./deadLock thread_routine_two:lock mutex two thread_routine_one:lock mutex one thread_routine_one:lock mutex two thread_routine_two:lock mutex one 2....
多线程——死锁DeadLock
weixin_47163086的博客
10-07 139
死锁 当两个线程互相等待对方释放同步监视器时会发生死锁，应避免这种情况出现： 避免多次锁定 尽量避免同一个线程对多个同步监视器进行锁定； 按相同的顺序加锁 如果多个线程需要对多个同步监视器加锁，则因保证它们以相同的顺序请求加锁； 可以使用超时释放发锁 调用Lock对象的tryLock(time,unit)方法，当超过指定时间后它会自动释放锁。 示例代码： package com.nefu; /** 死锁 */ public class ThreadDemo08 { public static v
Linux 多线程程序调用malloc，backtrace引发死锁问题的调试
DaliATOM的专栏
10-20 5250
信号处理函数必须是可重入函数，否则在多线程设计结构中容易造成不可预知的错误或造成程序死锁。
gdb调试分析多线程死锁
weixin_30932215的博客
02-10 320
转载： http://blog.chinaunix.net/uid-30343738-id-5757210.html #include <stdio.h> #include <pthread.h> #include <stdlib.h> #include <unistd.h> static int sequence1 = 0; ...
Linux内核死锁检测工具——Lockdep
嵌入式Linux充电站
12-25 2017
Linux内核在2006年引入了死锁调试模块`lockdep`，`lockdep`会跟踪每个锁的自身状态和各个锁之间的依赖关系，经过一系列的验证规则来确保锁之间依赖关系是正确。
信号处理函数陷阱：调用malloc导致死锁
木牛的博客
09-06 1277
其实不然，仔细分析，就会发现其中蹊跷：有一个线程，在执行malloc的过程中，跳转到了信号处理函数中。看了glibc源码就会知道，malloc内部也是有锁、而且是非嵌套的，如果在上一次调用中拿到锁，又跳转到信号处理函数中再次malloc，自然就导致死锁了。本人在项目中就曾两次遇到信号处理函数中调用不可重入函数导致的死锁：某项目运行一段时间后，进程基本停止响应各种外界命令，日志也基本停止打印(只有个别简单轮询线程定时大义些信息)，但ps命令看到进程还在运行。一般来说，信号处理函数中要做的事情应该尽量简单。
【Missing separate debuginfos, use: debuginfo-install glibc-2.17-222.el7.x86_64】 解决方法
11-28 620
Centos 7 系统，使用gdb调试C程序时，运行命令run时出现如下错误： Missing separate debuginfos, use: debuginfo-install glibc-2.17-222.el7.x86_64 解决方法： 第一步： 安装debuginfo-install yum install -y yum-utils 第二步：安装glibc-2.17 de...
linux 死锁问题查找方法
yangops的博客
03-28 4255
步骤 pstack 输出进程堆栈信息到文件，查找死锁线程 pstack 进程pid > t.txt Thread 2 (Thread 0x7f934774e700 (LWP 14248)): #0 0x00007f9b3569e54d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f9b35699e9b in _L_lock_883 () from /lib64/libpthread.so.0 #2 0x00007
linux死锁现象及分析方法
最新发布
04-11
Linux死锁现象是指发生多个进程或线程同时互相等待对方释放资源的情况，导致所有进程或线程都无法继续执行下去的情况。分析方法一般有两种： 1. 静态分析：通过检查代码、调用图、数据流等信息来分析潜在的死锁点； ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值