通常、PVS-Studioでプロジェクトを確認します。 今回は違った結果になりました。 LibreOfficeでPVS-Studioをテストしました。 そして、それにもかかわらず、彼らはチェックすることができ、その逆も可能です。
はじめに
プロジェクトの検査に関する記事は、読者とはまったく異なる反応を引き起こします。「これはどれくらい宣伝できますか？」から「ありがとうございます！」までです。 「公平に言えば、広告の専門家はプロジェクトの検証に参加せず、PVS-Studioの開発者と翻訳者のみが努力します。 アナライザーのオープンソースへの貢献は確かに小さくありません。 開発者は常にフィードバックに興味があるわけではありませんが、検証の手紙を受け取り、見つかったエラーを修正します。 LibreOfficeプロジェクトを例として使用します。この記事も近日中に公開されますが、プロジェクトチェックがアナライザー自体に及ぼす影響と実行された作業について説明します。
アナライザーについて
PVS-Studioは、C / C ++アプリケーションのソースコードのエラーを検出する静的アナライザーです。 アプリケーションの可能性とアナライザーの統合は絶えず拡大しており、機能を実証することに加えて、オープンソースプロジェクトはアナライザーの公平なテスターとして機能します。
LibreOfficeプロジェクトは、静的アナライザーの優れたテストであることが判明し、各PVS-Studioチームが機能するようになりました。
チェック時に発生した問題について説明します。
メモリリーク
LibreOfficeは、CygwinのMS Visual C ++ 2013を使用して構築されています。 PVS-Studio Standaloneユーティリティは最近、アセンブリシステムの詳細に入らずにプロジェクトをチェックし、「コンパイラモニタリング」をオンにしてプロジェクトのビルドを開始する機能を獲得しました。 この機能の詳細については、記事をご覧ください。PVS-Studioは、Windowsのビルドシステムとコンパイラをサポートするようになりました。 簡単ですぐに使用できます 。 つまり、同じ環境でプロセスを開始するために必要な情報は、Windowsで実行中のプロセスから抽出されます。 したがって、起動行、現在のディレクトリ、環境変数などを保存するために 数百キロバイトの管理されていないメモリが割り当てられます。 プロセスがサポートされているコンパイラに属している場合、情報はマネージメモリにコピーされ、アンマネージメモリはいずれにせよ解放されましたが、環境変数については判明したため、これは行われませんでした。 プロセスごとに、平均500キロバイトは解放されませんでした。 以前に検証されたプロジェクトでは、これは深刻な問題につながりませんでした（少なくとも、何かが間違っていて、ユーザーが苦情を言うことには気付きませんでした）。 Make by LibreOfficeによるビルドには、コンパイラに関連しない膨大な数の実行中のプロセスが伴います。 アセンブリの数時間以内に、10万を超えるプロセスが起動され、その結果、25ギガバイトが「滴下」しました。 この場所を修正すると、監視プログラムが使用するメモリサイズは1.8 GBに減少しました。
ロングチェック
ライブラリのコンパイルを含むアセンブリプロセス全体には、12,245のソースファイルが含まれていました。 残念ながら、このような数のファイルをチェックするプロセスには約15時間かかりました。そのため、アナライザーコアでいくつかの最適化が実行され、9時間でプロジェクトを再確認することができました。 これはプロジェクトのアセンブリ時間の2倍ですが、既に十分に適切で許容可能な速度です。
難易度分析
アナライザーがソースコード内の構造の解析に失敗した場合、アナライザーはこのファイルにV001メッセージを発行します。 アナライザーはこのようなコードのセクションをスキップし、ごくまれに検証結果に影響を与えます。 ただし、このプロジェクトに関するV001のメッセージは調査および修正されています。
古いパス形式
プロジェクトをチェックすると、「C：/PROGRA~2/MICROS~4.0/VC/include」などの古い形式のシステムパスが見つかりました。 この形式は、アナライザーコアとプラグインによって完全にサポートされていますが、システムファイルのメッセージのフィルター処理が機能しなかったため、対応する変更が加えられました。
シリアル化に失敗しました
この問題はPVS-Studio製品には当てはまりません。 LibreOfficeがテストされたPVS-Studioスタンドアロンユーティリティでは、ファイルナビゲーションが最近改善されました。これにより、含まれているヘッダーをナビゲートし、依存ファイル内のタイプと変数を検索できるようになりました。 すべての依存関係はスキャン中に収集され、* .plogファイルの近くに保存されます。 残念ながら、標準クラスのSystem.Runtime.Serialization.Formatters.Binary.BinaryFormatterは大容量構造のシリアル化に失敗します-内部例外がスローされるため、 プロトコルバッファライブラリが使用されるようになりました。
おわりに
LibreOfficeチェックの結果は、もう1つのオープンソースプロジェクトを改善し、PVS-Studio製品を適切に編集できるように設計された記事でした。 LibreOfficeで見つかったエラーに関する記事は、近日中に公開されます。 また、アナライザーの改善に役立ったLibreOfficeプロジェクトに感謝します！