#include
#include
#include
using
namespace std;
//互斥鎖
mutex mtx;
//執行緒共享資源
int i =0;
//執行緒入口函式
void
func()
intmain()
找到對應程式的pid，此處為10854，然後執行gdb -p 10854進入該程序的gdb除錯介面。
執行i threads列印當前的所有執行緒。執行結果如下：
id target id frame
2 thread 0x7fe06313f700 (lwp 10855)
) from /lib64/libpthread.so.0
* 1 thread 0x7fe06421e740 (lwp 10854)
) from /lib64/libpthread.so.0
從圖中第5條資訊就可以看出，程式當前執行到了testfordeadlock.cpp的第13行，正好就是對應實驗**中的mtx.lock()語句，可以判斷當前程式應該發生了阻塞。等待一段時間之後，再去列印該執行緒的堆疊資訊，可以發現其狀態並無改變，因此可以判斷在原始檔中第13行處發生了死鎖。
簡單的總結以下，上述死鎖發生的原因主要是在程式設計時，只對共享資源進行了加鎖，沒有解鎖，因此在第乙個執行緒訪問結束後，由於沒有解鎖就退出了，第二個執行緒再執行時，就會發生死鎖。可以看出實驗中的死鎖並不是真正意義上的死鎖，本文為了方便只是簡單的實驗了一下。
死鎖發生的四個必要條件：
避免死鎖的方法：
通過GDB快速定位「段錯誤」的位置
有些時候我們在一段 c c 的時候，由於對乙個非法記憶體進行了操作，在程式執行的過程中，出現了 segmentation fault core dumped 段錯誤。呵呵，這種問題我想很多人會經常遇到。遇到這種問題是非常無語的，只是提示了 段錯誤 接著什麼都沒有，如果我們一味的去看 找太疼苦了，因為...
Linux 下使用 gdb 定位 crash 位置
下面這一段 會出現segv錯誤。include int foo void int main void 執行後如下 foo 段錯誤 核心已轉儲 但是沒有發現 core 檔案。需要設定一下。ulimit c unlimited 再次執行生成 core 檔案。使用 gdb 除錯 gdb foo core ...
如何定位溢位點位置
程式 include void exploit void func intmain 關掉保護機制 gcc no pie fno stack protector z execstack m32 o 3.exe 3.c檢查一下 checksec 3.exe0x01 kali自帶msf pattern c...