我正試圖除錯一個執行緒問題。在大多數情況下，這很容易，但在這個問題上，有些東西被卡住了，我很難找到導致該問題的執行緒。(它發生在幾個小時之后，而且寫日志會破壞時間，所以......這很困難，因為我不能只是改變代碼來幫助我找到罪魁禍首）。
今天，我在想：
點擊Ctrl-C
我試圖確定它是哪個執行緒：
執行緒9 在哪里？這看起來是個好賭注。一個在FIFO上等待資料的執行緒...
我決定通過輸入來驗證我的理論：
完成程式再次啟動，但gdb從未停止......
我的想法是否正確？
我的想法是否正確，證明這個FIFO從未收到任何資料，這就是我的行程被卡住的地方？
uj5u.com熱心網友回復：
我的想法是否正確，這證明了這個FIFO從未收到任何資料
是的：如果你的描述是準確的，那么很可能是執行緒9被卡住等待資料。
這就是我的行程被卡住的地方？
這一點我們無法判斷。在 FIFO 上等待的執行緒可能正在期待來自外部源的資料（在單個行程內傳輸資料的 FIFO 有點不尋常，而且效率很低），如果 FIFO 的另一端與其他行程相連，那么執行緒被卡在那里的事實就不能證明什么。
P.S. 混合 FIFO 和執行緒導致掛起的常見方式之一是使用
fork或其他創建子行程的函式 -- 在多執行緒環境中要使這種代碼正確是極其困難的。轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/316547.html
標籤：