例としてClickHouseを使用した静的コードアナライザー

1か月ほど前、PVS-Studioを使用したClickHouseソースコードの分析を含む記事が公開されました。 記事は非常に成功したことが判明しました。たとえば、その記事へのリンクは、公開時に少なくとも1日に10回送信されました。 記事の全体的なトーンは好意的であり、その発行日のclickhouse.yandexウェブサイトのトラフィックは著しく増加しました。

会社や人が徹底的に仕事をするとき、私は本当に尊敬しています。 そのため、PVS-Studioにはプロモーションに対する包括的なアプローチがあります。Habrだけでも337の記事があります。 彼らは、ほぼすべてのロシアのC ++会議でプレゼンテーションを行います。 いずれにせよ、それは注目に値します。人々は自分の仕事で他の人々に利益を与えようとします。

その記事は静的アナライザーへの関心を喚起し、ClickHouseコードベースに基づいていくつかのパブリックPVS-Studioアナログの動作をテストすることにしました。 本日の記事では、この調査の結果を共有します。

記事がリリースされた日に、私たちはそこに記されているすべてのバグを修正しました。 結果はこのコミットで確認できます。 公開時のバグの中には、以前修正したためmaster



に存在しなくなったものがあります。

静的アナライザーの有用性については間違いありません。 一部のコメンテーターは、コードレビュー、テスト、サニタイザーの下での実行がはるかに有用であると指摘しています。 これらのソリューションの利点は明らかです。 さらに、すでにコードレビュー（中程度）、コミットテスト（カバレッジの悪い）、サニタイザー（ASan、1日1回Valgrindのみ）で実行されています。 静的アナライザーには、他のバグが見つかる場合があります。たとえば、実行されないコードのコピーアンドペーストで、1年前に削除する必要がありました。 そして、もっと深刻なものも見つける機会があります（続きを読む）。 つまり、静的アナライザーの利点はゼロではありません。

記事にすべての欠陥が示されているわけではなく、PVS-Studioの試用版ライセンスを使用して残りの欠陥を検索するよう提案されました。 しかし、限られた時間のライセンスを要求する前に、私たちはまず、時間を無駄にしないように準備ができていることを確認したかったのです。

PVS-Studioのいくつかの代替案を最初に研究することにしました。その結果、Clang-Tidy、ppcheck、Coverity、Svaceを試しました。 それぞれについて、ClickHouseコードでそれらを正しく使用する方法を説明することができました。

Cppcheck

使用手順： cppcheck.txt 。

このツールにはいくつかの重要な利点があります。非常に使いやすく、非常に高速に動作します。 そのため、数秒でリポジトリを分析しました。 標準の起動モードでは、少数の誤検知警告のみが発生しました。 --enable-all



モードでは、約200の警告が受信され、そのうちのいくつかは意味のあるものであることが判明しました。

• 誰かが1文字を入力するのを忘れた 。 ラッキー-エラーはプログラムの動作に影響しません。
• log1p関数を使用しない-そのようなものが存在することを知りませんでした。 この場合、プログラムの動作にも影響しません。

さらに、アナライザーは、関数にパラメーターを渡すとき、明示的な定義を忘れたとき、特定の変数のスコープが広すぎるなど、いくつかの非最適性も発見しました。

多くの誤検知は、アナライザーが非常に原始的であるという事実に関連しています。 どうやら、C ++を完全に解析することすらありません。 たとえば、次のコード

 int x = 0; auto lambda = [&]{ x = 1; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードのように扱われます：

 int x = 0; { x = 1; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、多数の誤検知が静的コードアナライザーの標準です。 それらを使用するシナリオは、数百のエラーを調べ、場合によってはそれらの中から本当に重要なエラーを見つけることです。

クランジー

使用手順： clang-tidy.txt

このツールの重要な利点は、Clangエコシステムにあることです。 つまり、システムがClangを使用してコンパイルされている場合、Clang-Tidyはプロジェクトのアセンブリのすべての機能を正しく考慮します。 独自のチェックを追加する方法についての指示があります。

Clang-Tidyは、各翻訳単位の分析に約12秒を費やします。 それは十分に遅いです。

Clang-Tidyは、スタイルチェックが存在する点でClang静的アナライザー（スキャンビルドとも呼ばれます）とは異なります。 一部のスタイルチェックでは、コードを自動的に書き換えることができます。 Clang静的アナライザーは、Clang-Tidyとは異なり、結果を含むHTMLページを生成できますが、Clang-Tidyは端末ウィンドウで見つかった問題に関するメッセージのみを表示することに注意してください。

すべての種類のチェックを使用することは意味がありません。 したがって、 CERT Secure Coding Standards 、 C ++ Core Guidelines、またはHTC ++のチェックの1つは、「ポインター演算を使用しない」と述べています。 ある意味、これは合理的ですが、このチェックをオフにする必要があるすべてのソースを明示的にマークするのは苦痛です。

有用なメッセージは、静的アナライザーとパフォーマンステストグループで見つかりました。 パフォーマンスは、イテレータのポストインクリメントと、参照渡しではなく値渡しの引数の受け渡しという2種類のエラーを検出しました。 残念ながら、参照による引数の受け渡しのチェックは、たとえば次のような小さな構造でも機能します。

 struct S { int x; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

またはSTRONG_TYPEDEF



。

この場合、値による送信を参照による送信に置き換えると、役に立たないか、有害でさえあることが判明する場合があります（関数がインライン化またはクローン化されていない場合、これらの場合は違いがないため）。 他の状況では、チェックがより有用であることが判明しました。commitcommitを参照してください。 もちろん、このようなエラーはコードレビューの段階で検出する必要があります-十分に注意している必要があります。 すべてのパフォーマンス警告を修正した後、ClickHouseの実際のパフォーマンスは変わらないことに注意してください。 これは予想されることです。対応するエラーがボトルネックにある場合、 sudo perf top



を初めて起動したときに気づいたでしょう。

静的アナライザーの警告は非常に便利です。

• コンストラクターでの仮想関数の呼び出し 。 仮想は誤って書いたことが判明した。
• 計算の精度の低下
• NULLポインターの逆参照 。

コベリティ

使用手順： coverity.txt

Coverityは非公開の商用製品ですが、オープンソースプロジェクトの場合は無料で使用できます。 Coverityを使用する有名な製品には、たとえばLinuxがあります。

作業スキーム：ビルドシステムをラップし（ cov-build make



代わりに単純に示されます）、コンパイラー呼び出しをインターセプトするユーティリティがサイトからダウンロードされます。 初めて彼女を働かせることはできませんでした。どのコンパイラを使用するかを彼女に伝える方法はいくつかありました。

一部の翻訳単位では、ツールは最大1時間実行され、プロジェクト全体の合計分析時間は4時間です。 その結果、Coverityにダウンロードできるtarballが作成されます。 1.5 GBのアーカイブが正常にダウンロードされました。 より多くの結果をダウンロードできます。

次に、アナライザーの結果にアクセスするために、分析されたプロジェクトのソースコードを操作する機能のテストに合格する必要があります。 たとえば、1日半アクセスが許可されました。

その後、美しいWebインターフェースが使用可能になり、欠陥注釈とメモ解決（誤検知、意図的、修正が必要など）を含むコードをインタラクティブに学習できます。

彼らはすぐにachivkaを発行しましたが、理由はわかりませんでした。

312個の欠陥が見つかりました。

• 構成内のユーザーがセクションのいずれかで要素を指定しない場合、 初期化されていない変数 。
• 終了反復子の逆参照は、単にアドレスに変換することです。
• すべての小さなもの 。

見つかったいくつかの欠陥は、実際には設計の一部です。

• テンプレートコードのifのトートロジー条件。 これは完全に正常であり、一般的な慣行およびコードスタイルです。 さらに、このコードは、コンパイラーがこれを非常によく知っており、不要なコードを削除するという前提で書かれています。
• デフォルトコンストラクターの初期化されていないクラスメンバー。 これは実際には間違いですが、場合によっては許容されます。
• テストプログラムのメイン関数で処理されない例外。 これにより、スタイルが可能になります。 メイン関数から例外がスローされた場合、std :: terminateを使用して処理されます。標準ライブラリはいくつかの便利なことを行います（詳細な終了ハンドラ）。 プログラムは中止信号を受け取り、オペレーティングシステムはコアダンプを書き込み、プログラムはゼロ以外のコードで終了します。 これはすべて非常に便利です。

さらに、エラーの1つは、std :: shared_mutexという形式のUnrecoverable parse error



ように見えました。 つまり、CoverityはC ++ 17をサポートしていません。

スエース

2016年11月30日、会議「Database Technologies」に参加しましたが、そこでは静的分析ツールSvaceの使用についてISP RASの同僚と同意することができました。 このツールはSamsungで実装されていますが、国内のプログラマーの間ではほとんど知られていません。

分析結果は、ソースコードと注釈を表示する便利なWebインターフェイスで利用できます。 見つかったエラーの中で最も深刻なのは、コード分岐の1つに freeaddrinfo がないことです。 分析の結果と研究のための欠陥の選択が、ISP RASの同僚から提供されたことは注目に値します。

結論

静的アナライザーの使用は、製品のコードを改善する最初の重要な手段ではありません。 たとえば、少なくともAddress Sanitizerでテストを実行する自動アセンブリがない場合は、最初にこれを提供する方が便利です。 静的アナライザーの結果の分析には、少なくとも最初から多くの時間が必要です。 それらを適切に使用するには、CIシステムへの統合が必要です。 より簡単なことを行った場合にのみ、静的アナライザーなどのすばらしいことを試すことができます。 しかし、なぜ私はあなたを思いとどまらせようとしているのです-必ず試してください！

結論として、PVS-Studioの同僚、特にClickHouseの記事に対して行っている仕事に感謝します。 これらは、コード内のいくつかの重要な問題を発見することで私たちを助けただけでなく、この記事が対象とする研究を刺激しました。