Linux 上のアプリケーションの問題をデバッグしようとしています。libstdc++.soまたはのランダムな場所で SIGSEGV でクラッシュする傾向がありlibstdc.soます。
私が追加したスレッドのジョブは非常に孤立しているため、明らかな競合状態はどこにもないようです。しかし、それでもほとんど常にクラッシュします。
アプリケーションは でコンパイルされg++ -c ... -pthread -D_REENTRANT、 でリンクされますg++ -pthread -o ...
しかし、関数の 1 つでほぼ常にクラッシュしていlibstdc*.soます。何が悪いのかを理解しようとして数日を無駄にしましたが、うまくいきません...
誰にもヒントはありますか？libstdc*.soスレッド対応としてコンパイルされていることを確認する方法はありますか? 私を助けることができるgdbコマンドはありますか? ヒープをデバッグしますか?
私は Linux を使って数年しか経っていないので、迷っています...
-gまだコンパイルしていない場合は、コンパイル時に使用して、シンボリックデバッガー情報を取得してください。
コアダンプされますか？その場合gdb、次のように実行可能ファイルに対してコアをロードするために使用できます。
gdb <my-exe> <my-core-file>
ロードされると（でコンパイルしたと仮定して-g）info threads、すべてのスレッドスタックのリストを取得し、問題の原因となったスレッドを調べるために使用できます。セグメンテーション違反の原因となったスタックトレースを追跡する場合、libstdc++.soまたはlibstdc.so何が起こっているのかが合理的に明らかであるはずです。少なくともそれはあなたを正しいエリアに連れて行くでしょう。
コアを取得できない場合、デバッガー自体の中でアプリを実行できますか？
この手法は、スレッドのデッドロックの根底に到達する場合にも非常に役立ちます。以下を使用してプロセスに接続するだけです。
gdb <my-exe> <my-process-id>
互いにロックしている2つのスレッドを探します。
あなたがしなければならないことがいくつかあります：
単体テストを書きます。スレッドの問題を見つけるのにはあまり役に立ちませんが、間違ったメモリ アクセスの問題を見つけるのに大いに役立ちます。