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

最新推荐文章于 2024-09-08 22:17:49 发布
最新推荐文章于 2024-09-08 22:17:49 发布
阅读量426 收藏
点赞数
文章标签： 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

迪迪一下
关注
Linux C++环境下避免死锁的全面策略解析与实践指南
探索C++编程的奥秘，分享深入的技术见解和实践，旨在激发读者创造力与解决问题的思维。
10-30 182
在本文中，我们深入探讨了在Linux C++环境下避免死锁的各种策略。通过对死锁的基本概念的解释，以及对不同避免策略的详细分析，我们提供了一套全面的方法来处理并发编程中的这一常见问题。
Linux死锁问题情况介绍及解决方法
IELLQUI6的博客
09-13 199
由于获取锁的顺序不一致，当Thread A获取到Mutex A后，由于Thread B已经持有了Mutex B，Thread A无法继续执行。这样，即使线程的执行顺序不同，也不会发生死锁。死锁是计算机系统中常见的并发问题之一，指的是两个或多个进程在互相等待对方持有的资源，导致系统无法继续执行下去的情况。死锁检测是一种动态死锁检测与恢复的方法，可以在运行时检测系统中是否存在死锁，并采取相应的措施进行恢复。请注意，以上提供的示例代码仅用于说明死锁问题的情况，并不保证在所有环境中都能复现死锁。
c语言 deadlock
01-16
c语言 deadlock
DeadLock
weixin_33853827的博客
06-24 319
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...
【Linux】 Linux 死锁
最新发布
2403_86785171的博客
09-08 1267
死锁指的是多个进程或线程因为互相等待对方持有的资源，导致这些进程或线程都无法继续执行的情况。死锁的典型场景是线程 A 锁住了资源 X，并等待资源 Y，而线程 B 锁住了资源 Y，并等待资源 X。由于双方都在等待对方释放资源，最终进入僵局。
Deadlock --- 死锁
zxz414644665的专栏
11-04 767
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 680
死锁（Dead Lock）指的是两个或两个以上的运算单元（进程、线程或协程），都在等待对方释放资源，但没有一方提起释放资源，从而造成了一种阻塞的现象就称为死锁。 比如线程 1 拥有了锁 A 的情况下试图获取锁 B，而线程 2 又在拥有了锁 B 的情况下试图获取锁 A，这样双方就进入相互阻塞等待的情况，如下图所示： 死锁的代码实现如下： import java.util.concurrent.TimeUnit; public class DeadLockTest { public st
线程的死锁和Lock锁
lidong777777的博客
07-21 349
本次博客带领大家了解死锁的基本概念和死锁的四个条件，Lock锁的用法。
linux死锁现象及分析方法
04-11
Linux死锁现象是指发生多个进程或线程同时互相等待对方释放资源的情况，导致所有进程或线程都无法继续执行下去的情况。分析方法一般有两种： 1. 静态分析：通过检查代码、调用图、数据流等信息来分析潜在的死锁点； ...
linux进程 crash 分析工具,crash工具分析大型Linux服务器死锁实战
weixin_30456235的博客
05-04 1220
Linux服务器背景：CPUS: 40MEMORY: 127.6 GBMACHINE: x86_64 (2199 Mhz)Linux Kernel: 4.4.121TASKS: 19411其实这不算大型服务器，我见过大型的一般内存4T起步，300多个cpu.故障背景：客户发现系统卡死，手动触发了kdump.使用下面命令发现有3092个D状态进程。crash> ps | grep UN | ...
linux内核挂死,用crash工具分析Linux内核死锁的一次实战分享
weixin_35647812的博客
04-30 1141
本文简介：内核死锁问题一般是读写锁(rw_semaphore)和互斥锁(mutex)引起的，本文主要讲如何通过ramdump+crash工具来分析这类死锁问题。0、背景知识点ramdump是内存转存机制，我们可以在某个时刻把系统的内存转存到一个文件中，然后与符号信息(vmlinux)一起导入到trace32或crash等内存分析工具中做离线分析。是分析崩溃、死锁、内存泄露等内核疑难问题的重要调试手...
死锁问题deadlock代码实现与解决
kcy的博客
04-26 418
涉及的相关命令 查看当前运行的进程： 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 1417
本案例借着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 171
死锁 当两个线程互相等待对方释放同步监视器时会发生死锁，应避免这种情况出现： 避免多次锁定 尽量避免同一个线程对多个同步监视器进行锁定； 按相同的顺序加锁 如果多个线程需要对多个同步监视器加锁，则因保证它们以相同的顺序请求加锁； 可以使用超时释放发锁 调用Lock对象的tryLock(time,unit)方法，当超过指定时间后它会自动释放锁。 示例代码： package com.nefu; /** 死锁 */ public class ThreadDemo08 { public static v
Linux 多线程程序调用malloc，backtrace引发死锁问题的调试
DaliATOM的专栏
10-20 5581
信号处理函数必须是可重入函数，否则在多线程设计结构中容易造成不可预知的错误或造成程序死锁。
gdb调试分析多线程死锁
weixin_30932215的博客
02-10 346
转载： 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; ...
利用GDB调试 MSQL
老叶茶馆
08-28 1347
作者：张政俊就职于中欧基金，知数堂粉丝，数据库爱好者，熟悉RDBMS、nosql、new sql等各类数据库。啃完O'reilly的《高性能mysql》、姜老师的《MySQL技术...
Linux内核死锁检测工具——Lockdep
嵌入式Linux充电站
12-25 2251
Linux内核在2006年引入了死锁调试模块`lockdep`，`lockdep`会跟踪每个锁的自身状态和各个锁之间的依赖关系，经过一系列的验证规则来确保锁之间依赖关系是正确。
信号处理函数陷阱：调用malloc导致死锁
木牛的博客
09-06 1542
其实不然，仔细分析，就会发现其中蹊跷：有一个线程，在执行malloc的过程中，跳转到了信号处理函数中。看了glibc源码就会知道，malloc内部也是有锁、而且是非嵌套的，如果在上一次调用中拿到锁，又跳转到信号处理函数中再次malloc，自然就导致死锁了。本人在项目中就曾两次遇到信号处理函数中调用不可重入函数导致的死锁：某项目运行一段时间后，进程基本停止响应各种外界命令，日志也基本停止打印(只有个别简单轮询线程定时大义些信息)，但ps命令看到进程还在运行。一般来说，信号处理函数中要做的事情应该尽量简单。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值