Linux用のPVS-Studioの作成方法

今年、私たちは長い間物議をかもしてきたこと、つまりPVS-Studio製品をLinuxシステムに適応させることを始めました。 この記事では、10年にわたるPVS-Studioアナライザーfor Windowsの後、Linuxディストリビューション向けの製品をどのように作成するかについて説明します。 残念ながら、一部のプログラマーが考えるように、これは多くの作業であり、限定されませんが、ターゲットプラットフォーム用のソースコードのみをコンパイルします。

はじめに

一般に、 PVS-Studioアナライザーのコンソールカーネルは長い間Linuxで構築されていました。 約3年間になります。 パブリックドメインにそのようなバージョンが存在しないという質問にすぐに答えます。既存のソフトウェア製品をベースにしたソフトウェア製品を作成することは、大きな仕事であり、多くの工数、予期せぬ問題やニュアンスが多くあります。 次に、これを予見しただけなので、Linuxシステムの公式アナライザーサポートは開始されませんでした。



私の同僚とは異なり、プロジェクト検証に関する多くの記事の著者である私は、Linuxプロジェクトからインスピレーションを得ました。 この環境には、Windows上で構築するのが非常に難しいか、不可能な大規模で興味深いオープンソースプロジェクトが豊富にあります。 これは、PVS-Studio for Linuxが今日までに開発したオープンソースプロジェクトをチェックするこのようなタスクのフレームワーク内にあります。



PVS-StudioカーネルコードをLinuxに移植するのに数か月かかりました。 システム関数への複数の呼び出しを置き換え、Chromiumプロジェクトでデバッグすることにより、すでに正常に機能するコンソールアプリケーションが提供されました。 このバージョンのアナライザーは、通常の夜間ビルドに追加され、Clang Static Analyzerでもテストされました。 開いているプロジェクトとアセンブリ制御の定期的なチェックにより、アナライザーは数年間問題なく存在し、時にはこのツールがすでに販売されているようにさえ見えました。 しかし、その時点で私がどのようにプロジェクトをチェックしなければならなかったかはまだわかりません...

静的分析ツールの使用について

ツールの開発に関する話を続ける前に、静的分析の方法論自体について少しお話ししたいと思います。 したがって、「エラーなしですぐにコードを記述し、同僚とレビューを行うことができる場合、なぜサードパーティ製ツールを使用するのか」というスタイルで質問にすぐに答えます。 残念ながら、この質問はよく聞かれます。



静的コード分析を使用すると、プログラムのソースコードのエラーや欠落を特定できます。 使用するツールに関係なく、これは将来のアプリケーションのコードの品質管理のための優れた方法論です。 可能であれば、さまざまな静的解析ツールを組み合わせると便利です。



会議の読者、ユーザー、またはリスナーの中には、同僚とコードをレビューするだけで、コード作成の初期段階でエラーを特定できると考える人がいます。 そして、そのような「検索」で何かがおそらく見つけられるでしょう。 しかし、今回も同じことについて話している。 実際、静的分析はコードレビューの自動化されたプロセスと考えることができます。 静的アナライザーが同僚のもう一人であると想像してください。 すべてのコードレビューに精力的に参加し、疑わしい場所を示す一種の仮想人間ロボット。 それは便利ではありませんか？！



多くの業界では、いわゆる「人的要因」を排除するために自動化に頼っています。 また、コード品質管理も例外ではありません。 手動のコードレビューを練習することを拒否することはお勧めしません。 静的アナライザーを使用するだけで、初期段階でさらに多くのエラーを検出できます。



もう1つの重要なポイント-プログラムは疲れたり怠けたりしません。 さまざまな種類のエラーがコードに導入されます。 タイプミス？ 目で区別するのは非常に難しいです。 言語エラー？ 審査官の資格に強く依存しています。 状況は、現代の大量のコードによって悪化しています。 多くの機能は、大型モニターでも完全には収まりません。 コンテキストが不完全な場合、検査官の警戒は低下します。 さらに、15分間コードを注意深く読んだ人は疲れ始めます。 そして、遠くなるほど強くなります。 したがって、毎年増加している自動分析ツールの人気。

PVS-StudioユーザーはLinuxバージョンに何を求めましたか？

当社の製品は、プログラムの開発に何らかの形で関係している人々にとって常に興味深いものでした。 これらは、アナライザーをすぐに試すことができるWindowsユーザーです。 一般のプログラマーでも、他のプラットフォームや言語のプログラマーでもありません。 そのような注意が期待されています 多くのエラーは多くのプログラミング言語に共通しています。



Linuxユーザーは、このプラットフォームのアナライザーについて長い間強く尋ねてきました。 質問と議論は次のように要約できます。

• コマンドラインユーティリティ-「IDEとの統合は不要です！」
• インストーラーは不要です-「すべてを自分でインストールします！」
• ドキュメントは必要ありません-「自分で実行しましょう！」

さらなるストーリーは、ユーザーの声明と彼らの期待との矛盾を繰り返し確認します。

アセンブリスクリプトを理解するという神話

大規模な商業プロジェクトの人々と話をした後、多くの開発者がプロ​​ジェクトの組み立てに精通していないことが判明しました。実際、そのような知識は必ずしも完全に必要ではありません。 各開発者は、自分のプロジェクト/モジュールをビルド/デバッグする方法を知っています。 しかし、通常、この知識はすべて、プログラマーが実行するいくつかの魔法のコマンドのセットです。 比ur的に言えば、大きなボタンがあり、クリックするだけで十分であり、出力では組み立てられたモジュールを取得します。 しかし、これらすべてが内部でどのように機能するかについては、一般的な考えしかありません。 また、アセンブリスクリプトは多くの場合、特別な人によって監視されます。



このような場合、少なくともアナライザーに慣れるには、統合なしでプロジェクトを検証するツールが必要です。



アナライザーのLinuxバージョンは、Windowsでコンパイラー監視システムを作成した直後に表示され、このプラットフォームでプロジェクトをチェックできました。 後で判明したように、Microsoftコンパイラーを使用して収集される多くの深刻なプロジェクトがありますが、Visual Studio用のプロジェクトはありません。 そこで、Qt、Firefox、CryEngine5のチェックに関する記事を執筆し、さらにEpic Games と協力して、コードのバグを修正しました。 調査では、コンパイラに関する情報（スタートアップディレクトリ、コマンドラインパラメータ、環境変数）を知っている場合、この情報でプリプロセッサを呼び出して分析を実行することができます。



Linuxプロジェクトをチェックする計画を立てていたときに、特定のプロジェクトごとにアナライザーの統合を理解できないことにすぐに気づいたので、ProcFS（/ proc / id's）に同様の監視システムを作成しました。 Windowsプラグインからコードを取得し、モノで実行してファイルを分析しました。 数年にわたり、この方法はプロジェクトのテストに使用されてきましたが、その最大のものはLinuxカーネルとFreeBSDです。 この方法は長期にわたって使用されていますが、大量使用には適していません。 製品はまだ準備ができていません。

監視技術の選択

そのような機能の必要性と重要性を決定したので、プロトタイプを作成して選択し始めました。

• （-）Clang scan-build-Clang'aスクリプトを確認した後、CC / CXX変数でアナライザー呼び出しを同様に登録するプロトタイプを作成しました。 この方法では、Clang Static Analyzerを使用して一部の開いているプロジェクトをチェックすることができないという事実に直面していました。 この方法をよく理解して、プロジェクトのこれらの変数にコンパイルフラグが追加されることが多いことに気付きました。 また、変数をオーバーライドする場合、保存できません。 そのため、この方法を放棄しました。
  
  
  
  
• （+）strace-ユーティリティはかなり詳細なトレースログを生成します。このログでは、ログに記録されたプロセスのほとんどはコンパイルに関連していません。 また、このユーティリティの出力形式には、プロセスに必要な作業ディレクトリがありません。 しかし、子プロセスと親プロセスをリンクすることでなんとかディレクトリを見つけることができ、C ++アプリケーションはこのようなファイルを非常に迅速に解析し、見つかったファイルの分析を並行して開始しました。 そのため、任意のアセンブリシステムでプロジェクトをチェックし、アナライザーに慣れることができます。 たとえば、最近、Linuxカーネルを再確認しましたが、簡単で簡単になりました。
  
  
  
  
• （+）JSONコンパイルデータベース-追加のフラグを1つ指定することで、CMakeプロジェクトのこの形式を取得できます。 分析に必要なすべての情報があり、不必要なプロセスはありません。 サポートされています。
  
  
  
  
• （±）LD_PRELOAD-関数置換によるアナライザーの統合。 プロジェクトが既にこの方法でアセンブルされている場合、このメソッドは機能しません。 LD_PRELOADを使用して非CMakeプロジェクトのJSONコンパイルデータベースを取得できるユーティリティ（ Bearなど ）もあります。 CMakeとは少し違いがありますが、サポートも行っています。 また、プロジェクトが設定された環境変数に依存しない場合は、プロジェクトを確認することもできます。 したがって、±。

定期的なテストの登場

ソフトウェアをテストするにはさまざまな方法があります。 アナライザーと診断をテストするための最も効果的な実行は、オープンプロジェクトの大規模なコードベースで実行されます。 まず、約30の主要なオープンソースプロジェクトを選択しました。 先ほど、Linuxで組み立てられたアナライザーが1年以上存在し、記事のプロジェクトが定期的にチェックされていることを述べました。 すべてがうまくいくように見えた。 しかし、本格的なテストを開始しただけで、アナライザーの欠陥の全体像がわかりました。 分析を開始する前に、コードを解析して必要な構成を見つける必要があります。 分離不可能なコードが分析の品質に与える影響はわずかですが、状況は依然として不快です。 すべてのコンパイラに非標準の拡張機能がありますが、MS Visual C / C ++で長い間サポートしており、GCCではほとんど最初からこの戦いを開始する必要がありました。 なぜほとんど？ Windowsでは、長い間GCC（MinGW）での作業をサポートしてきましたが、それほど普及していないため、私たちもユーザーも問題はありませんでした。

コンパイラー拡張

このセクションでは、GCC拡張機能を使用するコード、つまり他のどこにも見られないコードに焦点を当てます。 なぜ必要なのでしょうか？ ほとんどのクロスプラットフォームプロジェクトでは、使用される可能性は低いです。 まず、実践が示すように、それらが使用されます。 Linuxでプロジェクトをテストするためのシステムを開発するときに、このようなコードに出会いました。 しかし、標準ライブラリのコードを解析するときに主な問題が発生します。拡張機能が最大限に活用されています。 プロジェクトの前処理済みファイルを確認することはできません。最適化のために、使い慣れたmemset関数がステートメント式で構成されるマクロになることがあります。 しかし、まず最初に。 Linuxプロジェクトをテストするときに、どのような新しいデザインに出会いましたか？



見られた最初の拡張子の1つはイニシャライザに指定されました 。 それらを使用して、配列を任意の順序で初期化できます。 これは、 enumでインデックス付けされている場合に特に便利です。インデックスを明示的に指定することで、読みやすくし、将来変更する際の間違いの可能性を減らします。 それはとても素敵でシンプルに見えます：

enum Enum { A, B, C }; int array[] = { [A] = 10, [B] = 20, [C] = 30, }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スポーツの興味のために、この例を少し複雑にします。

 enum Enum { A, B, C }; struct Struct { int d[3]; }; struct Struct array2[50][50] = { [A][42].d[2] = 4 };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、この構造では、インデックス付けと構造体のメンバーの呼び出しのシーケンスを初期化子として使用できます。 範囲はインデックスとして指定することもできます：

 int array[] = { [0 ... 99] = 0, [100 ... 199] = 10, }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

小さいながらもセキュリティの観点から非常に便利なGCCの拡張機能は、nullポインターに関連付けられています。 NULLの使用の問題については、すでに多くの言葉が言われていますが 、繰り返しはしません。 GCCの場合、C ++のNULLは__nullとして宣言されるため、状況はわずかに改善されます 。 したがって、GCCは脚のそのようなショットから私たちを保護します。

 int foo(int *a); int foo(int a); void test() { int a = foo(NULL); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイルすると、エラーが発生します。

 test.c: In function 'void test()': test.c:20:21: error: call of overloaded 'foo(NULL)' is ambiguous int a = foo(NULL); ^ test.c:10:5: note: candidate: int foo(int*) int foo(int *a) { ^ test.c:14:5: note: candidate: int foo(int) int foo(int a) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GCCには、__ attribute __（（））属性を設定する機能があります。 リンク、アライメント、最適化、その他多くのことを制御できる関数、変数、および型の属性のリストがあります。 興味深い属性の1つはtransparent_unionです。 このようなユニオンを関数パラメーターにすると、引数としてユニオン自体だけでなく、この列挙からのポインターも渡すことができます。 このコードは正しいでしょう：

 typedef union { long *d; char *ch; int *i; } Union __attribute((transparent_union)); void foo(Union arg); void test() { long d; char ch; int i; foo(&d); //ok foo(&ch); //ok foo(&i); //ok }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

transparent_unionが使用する例は、 待機関数です。int*またはunion wait *を受け入れることができます。 これは、POSIXおよび4.1BSDとの互換性のために行われます。



おそらくGCCのネストされた関数について聞いたことがあるでしょう。 関数の前に宣言された変数を使用できます。 ネストされた関数をポインターで渡すこともできます（ただし、明らかな理由により、メイン関数の終了後にこのポインターで呼び出すことはできません）。

 int foo(int k, int b, int x1, int x2) { int bar(int x) { return k * x + b; } return bar(x2) - bar(x1); } void test() { printf("%d\n", foo(3, 4, 1, 10)); //205 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、そのような関数からgotoを「親関数」にできることを知っていましたか？ これは、そのような関数を別の関数に転送することと組み合わせて特に印象的に見えます。

 int sum(int (*f)(int), int from, int to) { int s = 0; for (int i = from; i <= to; ++i) { s += f(i); } return s; } int foo(int k, int b, int x1, int x2) { __label__ fail; int bar(int x) { if (x >= 10) goto fail; return k * x + b; } return sum(bar, x1, x2); fail: printf("Exceptions in my C?!\n"); return 42; } void test() { printf("%d\n", foo(3, 4, 1, 10)); //42 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、そのようなコードは非常に悲しい結果をもたらす可能性があるという事実です：例外の安全性は、Cを言うまでもなく、RAIIを使用したC ++でもかなり複雑なトピックです。したがって、そうしない方が良いです。



後藤と言えば。 GCCでは、タグを保存して、その後にポインターを置くことができます。 そして、配列に書き込むと、変換テーブルが得られます：

 int foo(); int test() { __label__ fail1, fail2, fail3; static void *errors[] = {&&fail1, &&fail2, &&fail3}; int rc = foo(); assert(rc >= 0 && rc < 3); if (rc != 0) goto *errors[rc]; return 0; fail1: printf("Fail 1"); return 1; fail2: printf("Fail 2"); return 2; fail3: printf("Fail 3"); return 3; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これはClangの小さな拡張です。 PVS-Studioは長い間このコンパイラを使用することができましたが、今でも言語とコンパイラに登場する新しいデザインに驚くことはありません。 それらの1つを次に示します。

 void foo(int arr[static 10]); void test() { int a[9]; foo(a); //warning int b[10]; foo(b); //ok }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このレコードを使用して、コンパイラは渡された配列に10個以上の要素があることを確認し、ない場合は警告を出します。

 test.c:16:5: warning: array argument is too small; contains 9 elements, callee requires at least 10 [-Warray-bounds] foo(a); ^ ~ test.c:8:14: note: callee declares array parameter as static here void foo(int arr[static 10]) ^ ~~~~~~~~~~~
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ベータ版のテストを終了しました。 ウェーブ1

アナライザーの安定したバージョン、ドキュメント、および統合せずにプロジェクトを検証するためのいくつかの方法を準備した後、クローズドテストを開始しました。



最初のテスターに​​アナライザーを発行し始めたとき、アナライザーに実行可能ファイルを提供するだけでは不十分であることがわかりました。 「すばらしい製品があり、多くのエラーが見つかりました」から「私はあなたのアプリケーションを信用していないので、/ usr / binにインストールしません！」というレビューを受けました。 残念ながら、後者の方が多かった。 したがって、実行可能ファイルでの独立した作業の可能性に関するフォーラムユーザーの議論は誇張されました。 この形式では、すべての人がアナライザーを使用できる、または使用したくないとは限りません。 Linuxでソフトウェアを配布するには、いくつかの一般的な方法を使用する必要があります。

ベータ版のテストを終了しました。 ウェーブ2

最初のレビューを受け取った後、テストを停止し、ほぼ2週間にわたってハードワークに没頭しました。 他の人のコードをテストすると、コンパイラに関するさらに多くの問題が明らかになりました。 なぜなら GCCに基づいて、さまざまなプラットフォーム用のコンパイラとクロスコンパイラが作成され、その後、当社のアナライザーを使用して、さまざまな鉄片のソフトウェアさえもテストし始めました。 原則として、アナライザーはその任務を処理し、感謝のフィードバックを受け取りましたが、アナライザーは、サポートする必要がある拡張機能のためにコードの一部をスキップしました。



誤検知は静的アナライザーに固有のものですが、Linuxではその数がわずかに増えています。 そのため、新しいプラットフォームとコンパイラの診断に取り組み始めました。



大きな改良点は、Deb / Rpmパッケージの作成でした。 登場後、PVS-Studioのインストールに対する不満はなくなりました。 おそらく、sudoを使用してパッケージをインストールすることに激怒した人は1人だけだったでしょう。 この方法でほとんどすべてのソフトウェアがインストールされますが。

ベータ版のテストを終了しました。 ウェーブ3

また、改訂のために短い休憩を取り、次の変更を行いました。

1. 迅速な検証のための構成ファイルの拒否-Deb / Rpmパッケージの導入後、最初の場所はアナライザーの構成ファイルに記入する問題で占められていました。 ライセンスファイルへのパスとアナライザーレポートへのパスの2つの必須パラメーターのみを使用して、構成ファイルなしでプロジェクトを迅速に検証するためにモードを変更する必要がありました。 このモードの詳細設定の可能性は残ります。
   
   
   
   
2. straceユーティリティのログの処理が改善されました。最初は、 straceユーティリティのログは、プロトタイプが作成されたPerl言語のスクリプトによって処理されていました。 スクリプトはゆっくりと動作し、分析の並列化が不十分でした。 この機能をC ++で書き直した後、ファイル処理は加速し、1つのプログラミング言語ですべてのコードをサポートすることも容易になりました。
   
   
   
   
3. Deb / Rpmパッケージの完成-as クイックチェックモードが機能するには、 straceユーティリティが必要で、最初のパッケージにPerl / Pythonスクリプトが含まれていたため、すべての依存関係がすぐに正しく登録されず、後でスクリプトが完全に破棄されました。 後に、グラフィカルマネージャーを使用してアナライザーをインストールする際の警告について何人かの人々が書いたので、すぐにそれらを削除しました。 ここで、私たちが自分用に設定したテスト方法の利点に注目したいと思います。数十のLinuxディストリビューションがDockerにデプロイされ、インストールされたパッケージがインストールされます。 インストールされたプログラムを実行する機能もテストされました。 このようなテストにより、パッケージに新しい変更をすばやく加えてテストすることができました。
   
   
   
   
4. アナライザーとドキュメントのその他の改善。 すべての成果をドキュメントに反映しました。 さて、アナライザーのファイナライズに関する作業は止まりません。これらは新しい診断と既存の診断の改善です。

ベータ版のテストを終了しました。 ウェーブ4（リリース候補）

アナライザー配布の最後の波では、ユーザーはアナライザーのインストール、開始、および構成に問題がなくなりました。 ありがたいフィードバック、見つかった実際のエラーの例、誤検知の例があります。



また、ユーザーはアナライザーの高度な設定に関心を持つようになりました。 そのため、アナライザーをMakefile / CMake / QMake / QtCreator / CLionに統合する方法についてのドキュメントの改善を開始しました。 それがどのように見えるか、私はさらに示します。

十分に開発された統合方法

Makefile / Makefile.amでの統合

統合せずにプロジェクトをチェックする便利さにもかかわらず、アセンブリシステムに直接統合することにはいくつかの利点があります。

• アナライザーの微調整。
• 増分分析;
• アセンブリシステムレベルでの分析の並列化。
• 組立システムのその他の利点。

アナライザーがコンパイラーと同じ場所で呼び出されると、環境、作業ディレクトリー、およびすべてのパラメーターがアナライザー用に正しく構成されます。 この場合、すべての条件が満たされ、正しい定性分析が行われます。



Makefileでの統合は次のようになります。

 .cpp.o: $(CXX) $(CFLAGS) $(DFLAGS) $(INCLUDES) $< -o $@ pvs-studio --cfg $(CFG_PATH) --source-file $< --language C++ --cl-params $(CFLAGS) $(DFLAGS) $(INCLUDES) $<
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CMake / CLionの統合

CMakeでのアナライザーの統合を検討した結果、CLionでPVS-Studioを使用できるようになりました。 アナライザーレポートのファイルを受信するか、IDEで警告を表示して問題のある領域を表示できます。

CMake / QtCreatorでの統合

QtCreatorでCMakeプロジェクトを操作するには、レポートを保存するか、IDEでアラートをすぐに表示することもできます。 CLineとは異なり、QtCreatorはTaskList形式で保存されたレポートを表示するために開くことができます。

QMake / QtCreatorでの統合

QMakeプロジェクトでは、簡単な統合方法も提供しました。

 pvs_studio.target = pvs pvs_studio.output = true pvs_studio.license = /path/to/PVS-Studio.lic pvs_studio.cxxflags = -std=c++14 pvs_studio.sources = $${SOURCES} include(PVS-Studio.pri)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

開発中に何に到達しましたか：

1. アナライザーは、パッケージまたはリポジトリから簡単にインストールできます。
2. アナライザーをアセンブリシステムに統合せずにテストを実行することにより、アナライザーを簡単に理解できます。
3. アナライザーを定期的に使用するために、各開発者のマシンで増分分析を構成できます。
4. ビルドサーバーでフルスキャンを設定します。
5. 一般的なIDEとの統合。

そのような楽器はすでに人々に見せることができます。



こちらからアナライザーをダウンロードして試すことができます。 私たちのニュースをフォローし、検証のためにプロジェクトを送信しましょう、今はLinuxで！





この記事を英語圏の聴衆と共有したい場合は、翻訳リンクSvyatoslav Razmyslov： The Development History of PVS-Studio for Linuxを使用してください。