Linuxでのスレッド問題のトラブルシューティング方法

Question

Linux上のアプリケーションで問題をデバッグしようとしています。ランダムな場所でSIGSEGVがlibstdc++.soまたはlibstdc.soにクラッシュする傾向があります。

私が追加したスレッドのジョブは非常に分離されているので、どこにでも明らかな競合状態はないようです。しかし、それはほとんどすべての時間クラッシュします。

アプリケーションはg++ -c ... -pthread -D_REENTRANTでコンパイルされ、g++ -pthread -o ...

にリンクされたが、それはまだlibstdc*.so機能の一つで、ほぼすべての時間をクラッシュますされています。私は何が間違っているのか理解しようと数日を無駄にしました...

誰にもヒントはありますか？ libstdc*.soがスレッド認識としてコンパイルされていることを確認する方法はありますか？私を助けることができるどんなgdbコマンド？デバッグヒープ？

あなたがすべきいくつかのことがありますが、私はほんの数年前からLinuxに働いているので、私は迷ってしまいました...

Answer 1

：

• はhellgrind
• を使用してアプリケーションを実行しますvalgrind's memory check
• DRD

を使用してアプリケーションを実行するを使用してアプリケーションを実行します

ユニットテストを書く。スレッドに関する問題を見つけるのにはあまり役立ちませんが、間違ったメモリアクセスの問題を発見することで大きな助けになります。

Answer 2

まだコンパイルしていない場合は、コンパイル時に-gを使用して、シンボリックデバッガーの情報を取得してください。

コアをダンプしますか？

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

を一度ロードされた（あなたが-gしてコンパイル仮定）を使用すると、すべてのスレッドスタックのリストを取得し、見てとることinfo threadsを使用することができます。その場合は次のように実行ファイルに対してコアをロードするためにgdbを使用することができます問題を引き起こしたスレッドsegフォールトの原因となったスタックトレースを、libstdc++.soまたはlibstdc.soから追跡すると、何が起きているのかは分かりません。少なくともそれはあなたを正しい場所に連れて行きます。

コアを取得していない場合は、デバッガ自体でアプリを実行できますか？単純に使用してプロセスにアタッチ：

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

、お互いをロックされている2つのスレッドを探し

また、この技術は、スレッドのデッドロックの底になってFO非常に便利です。