問題タブ [thread-sanitizer]

--thread-sanitizerOSXでclangのオプションを使用しようとしています:

リンクエラーのようです。追加のライブラリとリンクする必要がありますか?

これは、データ競合を報告するthreadsanitazer (clang) からのペーストです http://pastebin.com/93Gw7uPi

グーグルで調べてみると、これはthreadsanitazerの問題のようです（たとえばhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507）

だから、これが次のように見えるとしましょう（これは今手作業で書かれているので、コードが機能していません）：

メインスレッドで新しいスレッドが作成され（これは実際には別のクラスにあります）、新しい io_service ハンドラに対して実行されます

メインスレッド要素から定期的に追加または削除されます

したがって、この場合、ドキュメント (個別の shared_ptr (boost または std) が複数のスレッドからの読み取り/書き込みアクセスを許可すると記載されている) から判断すると、データ競合が発生する可能性がありますか?

このコードは、1 つのポインターに対して 2 つの別個の shared_ptr インスタンスを適切に作成しますか?

shared_ptr.h でアトミック操作を確認できるので、誤検知を報告するスレッド サニタザーに問題があることを確認したいだけです。

私のテストでは、これはメモリ リーク (shared_ptr インスタンスが適切に削除され、デストラクタが呼び出される)、セグメンテーション違反など (要素の挿入/削除に 10 時間 - 1 秒あたり 100 または 1 秒ごと) なしで正しく動作します。

スレッド サニタイザーを試すために、意図的にデータ競合を含む小さな C++ プログラムを作成しました。確かに、tsan はエラーを検出します。しかし、私は生成されたメッセージに困惑しています...

1. 書き込みと書き込みのデータ競合が報告されますが、読み取りと書き込みの競合が予想されます。find()が私のコンテナに書き込まれないことを望んでいたでしょう。constのバージョンを取得しようとしてさらに小さなコード調整を行うとset::find()、同じ書き込みと書き込みの競合が残るようです。
2. これは、同じアドレスでの 4 バイトのアトミック書き込みと 8 バイトの書き込みの間の書き込み競合を示しています。コンテナ クラスの同じフィールドが 2 つの異なるアクセス タイプからアクセスされるのは奇妙に思えます。

find()STL コンテナーに書き込まないconst を使用するオプションはありますか?

これはテスト済みの C++ プログラムです。

そして、これは tsan 出力 (の一部) です:

フィードバックをありがとう、ジョス

次のコードを見てください。

これは、 Boost.Atomicの参照カウントの例に多少似ています。

主な違いは、組み込みref_count_がコンストラクターで初期化さ1れること (コンストラクターが完了すると、ReferenceCountedオブジェクトへの参照が 1 つになる) と、コードが を使用しないことboost::intrusive_ptrです。

コードで使用したことで私を責めないでください。delete thisこれは、私が職場の大規模なコード ベースで使用しているパターンであり、今のところ私にできることは何もありません。

このコードをclang 3.5from trunk (詳細は下記) とThreadSanitizer (tsan v2) でコンパイルすると、ThreadSanitizer から次の出力が得られます。

奇妙なことは、参照カウンターでアトミックデクリメントを行うときthread T1と同じメモリ位置にサイズ 1 の書き込みを行うことです。thread T2

前者の書き込みはどのように説明できますか? ReferenceCountedクラスのデストラクタによって実行されるクリーンアップですか？

偽陽性ですか？それともコードが間違っていますか？

私のセットアップは次のとおりです。

コードは次のようにコンパイルされます。

私のマシンでは、 の実装は、 ThreadSanitizer が理解していると主張する一連の関数にboost::atomic<T>解決されることに注意してください。__atomic_load_n

更新 1:clang 3.4最終リリースを使用する場合も同じことが起こります。

更新 2: libstdc++とlibc++の両方-std=c++11で同じ問題が発生します。<atomic>

大規模なプロジェクトで ThreadSanitizer の警告をクリーンアップする作業を行っています。特にこの正確なケースでは、ファイル、プロデューサーから読み取る生成されたスレッドがあります。次に、スレッド プールの一部として 1 つ以上の圧縮解除スレッドがあります。最後に、解凍されたブロックを取得して実際に処理を行う 1 つのスレッドがあります。もちろん、これにより、複数のブロックを同時に解凍できます。

プロジェクトがアトミック bool と を介して同期する場所はたくさんありますがusleep()、特にこれを含みます。もちろん、これは理想的ではなく、私に割り当てられたものの 1 つです。

しかし、ミューテックスとロックが表現されている限り、ThreadSanitizer が不平を言う問題が何であるかはわかりません (condition_variable を使用する場合と比較して潜在的に効率が低下することを除いて)。

ThreadSanitizer は、「スリープ経由で同期されているかのように」データ競合について不平を言い、usleep()呼び出された場所の場所を提供します。私の問題は、もちろんスリープによる同期は理想的ではないということですが、ミューテックスが尊重されている限り、データ競合は見られません。ミューテックスの仕組みを理解している限り、それらは尊重されていると思います。

そのため、ThreadSanitizer が不平を言っていることを正確に特定するために、再現手順の最小限のセットを作成しようとしています。

これが私が思いついたコードです：

最初のコメントが示すようにそのコードをコンパイルすると、GCC 4.9.1 を使用して、実行の最後に ThreadSanitizer から次のメッセージが表示されます。

すべてのスレッドが結合された後、ラムダ、具体的には共有ポインターのデストラクタのように見えるもので、tsan は最終的に「スリープ経由で同期されているかのように」と不平を言います。これは C++11 の機能であり、Google は ThreadSanitizer が C++11 をあまり好まないという多くの証拠を提供しているため、それ自体は「本当の」競争ではないと思います。

とはいえ...ラムダがスレッドへのエントリポイントとして使用されているという事実...ラムダが破棄される前にスレッドが完全に終了していない実際のレースなのだろうか？それはコンパイラのバグの領域にあるため、これ以上調査する必要はありません (スコープ クリープなど)。

だから私の質問（私はそれらがいくらかオープンエンドであることを知っています、それらを絞り込むのを手伝ってください？）

この場合、ThreadSanitizer がプロデューサー、デコンプレッサ、およびコンシューマで「スリープ経由で同期されたかのように」データ競合を検出しないのはなぜですか? さらに、このコードを変更して...

A) ...「通常」クラッシュを引き起こさない ThreadSanitizer 警告を発行する真のデータ競合を生成します (問題のソフトウェアの現在の製品リリースは、この想定されるデータ競合の結果としてクラッシュするようには見えません)?

B) ...一見するとデータ競合ではないように見えますが、知識や経験からそうではないことが明らかになる真のデータ競合を生み出しますか?

C) ...ThreadSanitizer から偽陽性を生成しますが、実際にはデータ競合はありません。

Gcc のスレッド サニタイザーに問題があり、bugzilla または stackoverflow で見つけることができないため、何かが足りないのか、それとも本当にバグなのかわかりません。以下を含む main.cpp ファイルを作成した場合:

今、次を使用してコンパイルすると:

結果の実行可能ファイルを実行しても、問題は発生しません。それでも、デバッグ情報フラグを追加すると:

次に、スレッド サニタイザーがデータ競合を検出します。

これで、clang++ (バージョン 3.6.0 (トランク 221144)) でコンパイルされたまったく同じコードがデータ競合を検出しなくなりました。

私は gcc からのこの動作について少し疑問があります: 1) スレッドへの引数として空のラムダ関数を渡すことは、私には理にかなっているように思えます 2) gcc の動作は -g フラグに依存していますが、やるべきことがたくさんあるとは思えませんスレッドサニタイザーを使用 3) 同様の状況下で、clang は私が正しいと考える動作を採用します

どうもありがとう、

ThreadSanitizer抑制ファイルとブラックリスト ファイルに違いはありますか? -- -fsanitize-blacklist= の llvm 固有のコンパイラ フラグによって使用される場合

いつどちらを使用する必要がありますか?