如何解決Linux上的線程問題？

我想在Linux上調試一個應用程序的問題。它往往會在隨機的libstdc++.so或libstdc.so處與SIGSEGV崩潰。如何解決Linux上的線程問題？

在任何地方似乎沒有明顯的競爭條件，因爲我添加的線程中的工作非常孤立。但它幾乎一直都在崩潰。

應用程序被編譯與g++ -c ... -pthread -D_REENTRANT，並與g++ -pthread -o ...

連接，但它仍然崩潰幾乎所有的libstdc*.so功能之一的時間。我已經浪費了幾天的時間，試圖找出有什麼問題，但沒有去...

有沒有人有任何提示？有沒有辦法確保libstdc*.so被編譯爲線程感知？任何可以幫助我的gdb命令？調試堆？

我與Linux的工作只有幾年，所以我輸了...

2012-05-02 Coder

你可以發佈代碼的相關部分？ – hmjd

你想要一些帶有蠕蟲的芥末醬嗎？ – PlasmaHH

@hmjd：不幸的是，它是一個已經很大的代碼庫，它擴展了多線程。我無法爲其子集創建複製場景。因此，我正在尋找可以提供幫助的技術，這就是我所能做到的。 – Coder

有幾件事情你應該做的：

您的應用程序

編寫單元測試。雖然他們對尋找線程問題沒有多大幫助，但他們可以幫助您找到錯誤的內存訪問問題。

2012-05-02 10:35:13

如果您還沒有編譯，請嘗試使用-g以獲取符號調試器信息。

你有傾倒的核心嗎？如果是這樣你可以使用gdb加載核心對可執行如下：

gdb <my-exe> <my-core-file>

一旦加載（假設你有-g編譯），你可以使用info threads讓所有的線程棧的列表，看看導致問題的線程。如果您遵循導致seg故障從libstdc++.so或libstdc.so備份的堆棧跟蹤，應該明確地發現所發生的情況。至少它會讓你到正確的地區。

如果你沒有獲得核心，你可以在調試器本身內運行你的應用程序嗎？

這種技術也越來越FO到線程死鎖的底部是非常有用的：只要連接到使用過程：

gdb <my-exe> <my-process-id>

，並尋找兩個線程被鎖定對方。

2012-05-02 10:59:41

我通過'gdb myapp'，然後'r'，'SIGSEGV'，'bt'，'info threads'啓動應用程序。我有調用堆棧，但是它們在'libstdc * .so'內'malloc'和'new's失敗 – Coder

聽起來像是你的運行時庫安裝被搞砸了，或者你的編譯和運行時環境之間存在不兼容。你是否從頭開始重建所有內容並檢查了'LD_LIBRARY_PATH'或同等的內容？ –

當然，但是什麼函數調用'malloc'和'new's？查看調用堆棧，直到看到與您的軟件堆棧相關的函數，而不僅僅是在clib中。 – snies

回答