如何尋找多執行緒程式的bug

2021-10-25 03:29:11 字數 1349 閱讀 8564

3. 縮小錯誤範圍

4. 總結

確保程式以單執行緒方式執行時沒有錯誤。這是找bug的基礎。

可能原因1：對mutex使用lock後忘記解鎖

例如：沒有對每一種可能的情況進行unlock。

mutex m1;


thread1


m1.unlock()


;return


;}
可能原因2：發生死鎖

例如：使用普通鎖對遞迴程式加鎖。

mutex m1;


void


func1()
可能原因1：資料競爭導致的陣列越界錯誤。

例如：

atomic<


int> index =0;


vector<


int> vec;


intfunc


(int n)


thread1


thread2
可能原因：資料競爭，沒有對共享的全域性變數做有效保護。

舉個例子：

atomic<


int> index =0;


thread1


thread2
即使保證輸入資料完全不變，結果也會出現時對時錯的情況。這種問題基本上不會出現在單執行緒程式中。

可能原因：仍然是資料競爭，但與2.3的區別在於，大部分時候程式運算的結果都是正確的。我們知道，資料競爭這類多執行緒錯誤，往往發生在乙個執行緒讀完共享變數但沒來得及寫時，另乙個執行緒闖入並修改共享變數導致的。所以這樣的小概率錯誤就提醒我們，執行緒中對某個共享變數的讀和寫沒有得到保護，但由於讀操作和寫操作的位置非常近，使得其他執行緒恰好在讀和寫的間隔中修改了共享變數的概率很低。

舉個例子：

atomic<


int> index =0;


thread1


thread2
其實可以看到，這仍然是乙個很普通的多執行緒錯誤。但是兩個執行緒下其他**占用99%以上的時間，這就導致恰好在index++;和int a = index;之間切換執行緒的概率很低。

如果第2步仍然沒有幫你找到程式的錯誤所在，那麼就不得不使用比較麻煩的方法，一步步縮小錯誤範圍。

將最大執行緒數設定為1，測試是否會發生錯誤。如果會發生錯誤，說明bug出現在多執行緒程式額外引入的各種原子變數或者多執行緒容器上，而不是資料競爭。

在每兩個步驟之間抽取出中間結果，與正確程式的中間結果進行對比。如果一樣說明沒有問題。

注意：在某些程式中，使用多執行緒時中間結果不一樣反而是正常的。

結合2與3中方法，應該能大致定位出bug所在。

vector配合多執行緒的bug

近日加利福尼亞大學同學來訪問，寫的程式core了，幫忙除錯好半天。紀錄一下奇葩的bug。起始bug的原因挺容易想到的，而且也是寫 的時候應該注意的地方。應為vector記憶體動態增長的原因，vector中的元素的指標和引用都是不可靠的。當然這一點在單執行緒時基本沒有問題。但是多執行緒就跪了。多執行緒...

python程式多執行緒 PYTHON多執行緒

在單執行緒的情況下，程式是逐條指令順序執行的。同一時間只做乙個任務，完成了乙個任務再進行下乙個任務。比如有5個人吃飯，單執行緒一次只允許乙個人吃，乙個人吃完了另乙個人才能接著吃，假如每個人吃飯都需要1分鐘，5個人就需要5分鐘。多執行緒的情況下，程式就會同時進行多個任務，雖然在同一時刻也只能執行某個任...

多執行緒程式的除錯

gdb對於多執行緒程式的除錯有如下的支援 gdb r starting program root thread new thread 1073951360 lwp 12900 new thread 1082342592 lwp 12907 以下三個為新產生的執行緒 new thread 109073...