我試圖調試一個非常罕見的死鎖，並將其縮小爲pthread_mutex，它是類型1（遞歸）的問題。我想跟蹤這個互斥體來自哪裏，因爲我們所有的代碼都使用普通的互斥體，所以我認爲檢測互斥體類型==遞歸來追蹤它是有意義的。使用gdb調試pthreads
我試過在pthread_mutex_lock中設置一個手動斷點，通過堆棧指針等取消引用pthread_mutex_t來檢查它的類型，但是這被稱爲數百萬次，並且它會花費永遠的時間來捕捉互斥類型==遞歸的情況。
我也試着插入一個圖書館和的pthread_mutex_lock更換，使互斥型可以設置斷點，但沒有得到任何安打（不相信這是捕獲所有的來電對pthread_mutex_lock）
我得到在每次使用類型爲遞歸的互斥體調用pthread_mutex_lock時，都必須有一種設置觀察點/條件斷點的gdb方法？
以上任何幫助將不勝感激。提前致謝。
代替gdb斷點，可以使用觀察點
你可以嘗試：
(gdb) conditional yourbreakpointid mutex.__m_kind==PTHREAD_MUTEX_RECURSIVE
哪裏mutex是你放置在中範圍的互斥和yourbreakpointid斷點的ID名稱功能。
__m_kind可能根據實現更改名稱，搜索您的分發標頭（pthread.h），如果這不起作用。
謝謝 - 我試過這個，但由於某種原因，gdb無法解析互斥參數（不記得確切的錯誤信息，直到星期二我都無法訪問我的機器）。我會再試一次，聽起來好像應該起作用。 – user1621986
我無法讓gdb解釋傳遞給pthread_mutex_lock的互斥參數。問題是傳遞的參數是「互斥體」，但是當我在pthread_lock_mutex中，並且執行ptype互斥體時，它返回std :: mutex，所以當我嘗試做「嘗試使用類型名稱作爲表達式」時任何事情。我原本以爲這可能是一個gdb的錯誤，但我現在正在運行最新的，仍然沒有喜悅。我也嘗試靜態鏈接pthreads無濟於事！任何幫助非常感謝:)！ – user1621986
@ user1621986您是否試過使用':: mutex'，告訴gdb這不是您引用的'std :: mutex'，而是全局命名空間中的變量？ –
我已經將範圍縮小到了pthread_mutex，這是1型（遞歸）的一個問題...
我想追查這哪裏是互斥的，並因爲我們所有的代碼使用的未來正常互斥
想必你已經以某種方式確定你的線程（或多個）被阻擋在pthread_mutex_lock試圖鎖定一個遞歸互斥體，而你不知道是誰在持有該互斥體，以及爲什麼。
堆棧跟蹤導致pthread_mutex_lock應該告訴你該代碼試圖鎖定該互斥體，這是所有你應該知道了解問題究竟。
我不明白你爲什麼要「抓」鎖定該互斥體的行爲的pthread_mutex_lock的，因爲這將有可能不給你任何比你已經有更多的信息通過後，你看堆已經發現了這個僵局。
一般來說，試圖調試GDB的互斥鎖問題是徒勞的 - 設置斷點（甚至只是附加GDB）的行爲會將操作的時間更改爲這樣的程度，以至於大多數問題在運行時不會顯示根據GDB。
我接受你的觀點，但不幸的是，堆棧跟蹤在死鎖點顯示爲不完整/損壞（大量的），因此我無法看到足夠的幀以確定每個線程所遵循的代碼路徑到達那裏（我可能需要了解更多關於手動跟蹤堆棧指針的信息）。我同意死鎖不太可能在gdb下顯示出來，但是，我在考慮追蹤遞歸互斥（在正常操作期間）的起源可能會讓我更好地瞭解線程3獲取鎖的位置（取決於代碼的數量路徑正在使用遞歸互斥體:)）。 – user1621986
謝謝。是的，觀察點可以工作，但是我不確定的一點是如何計算要監視的內存地址，以便通過類型遞歸來監視對pthread_mutex_lock的所有調用。 – user1621986