Makefileの処理を追跡、ビルドに起因するバグを発見

図1　Build Analysisによるビルド・プロセスの解析結果
画面はビルド時間の解析画面で、どのファイルのコンパイルにどの程度の時間がかかっているかをヒストグラム表示する。ほかに、各プロセスの起動順を表示する機能なども備える。

 

　ソフトウエアの開発工程の中で、最も時間が長くかかるのがテストとデバッグだ。最近ではソース・コード上に紛れ込んだバグを検出したり、実行時の振る舞いを調べてバグの発見を支援したりするデバッグ支援ツールがそろってきており、テスト/デバッグ作業の生産性は向上しつつある。たが中には、このような既存のデバッグ支援ツールでは発見できないバグもある。

その1つが、ソース・コードに起因するのではなく、ソース・コードから実行モジュールを生成するビルドのプロセスが原因のバグだ。実行ファイルを生成できなくなるようなビルド・プロセスのバグは比較的見つけやすいが、ビルドに異常に長い時間がかかったり、初回は正しくビルドできるのに2回目以降は正しくビルドできなかったり、一見正しく実行ファイルが生成されたように見えても正常に実行できなかったりするような場合は、その原因を見つけにくい上に、そもそもビルド・プロセスに問題があることに気が付かないことが多いものだ。

米Coverity社が発売した「Build Analysis」は、そのようなビルド・プロセスの問題点を見つけ出すツールである。ビルド・スクリプト（Makefile）によって起動されるプロセスのOSに対するAPIコールを監視して、実行されたプロセスの種類や、各プロセスが読み出したり書き込んだりしたファイルなどを記録する。Build Analysisはこれらのデータを基に、ビルド・プロセスの流れや、処理時間の分布を可視化して画面に表示する（図1）。ソフトウエア開発者が見ればビルド・プロセスの流れが一目で分かり、問題点の発見が容易になる。

さらに、各種チェッカを用意しており、ファイルへのアクセス違反がないかどうか、クリーンナップ時に削除されないファイルがないかどうか、プロセスの多重起動がないかどうかを自動的に検査できる。例えばクリーンナップ時に削除し忘れるファイルがあると、古いオブジェクトがリンクされかねない。プロセスの多重起動は、ビルド時間が長くなるだけでなく、複数の実行ファイルが1つの共通オブジェクトをそれぞれリンクするような場合に、整合性が取れなくなる原因になってしまうことがある。

ビルドの履歴情報も記録するので、例えば初回のビルドは正常終了したが、2回目はビルドできなくなったという場合は、正常動作時のビルド・プロセス・データと異常動作時のデータを比較することで、問題を見つけやすくなる。

Build Analysisは、x86向けのLinuxまたはSolaris上で動作する。Coverity社では、今後はWindowsにも対応予定だとしている。処理系については、GCC（GNU Compiler Collection）などのC/C++のビルド・システムに対応しており、特定の処理系には依存しないとしている。今後はJavaにも対応予定だ。なお、ターゲット・マシンのプロセッサがx86以外であっても、パソコン上でクロス開発する場合は適用可能である。例えばARMプロセッサを採用した組み込み機器向けソフトウエアの開発時にも、パソコン上でクロス開発するならば適用できる。

価格は、Build Analysisのほか、ソース・コードの静的解析ツール「Prevent」とソフトウエアの構造解析ツール「Architecture Analysis」、ソフトウエアの動的解析ツール「Dynamic Analysis」の4つのツールがセットになった「Integrity Center」が、解析対象のソース・コード1000行につき1万2250円（年間ライセンス）である。Build Analysisを単体では販売しない。

【関連記事】
・独自の方式でバグに挑む ～ コベリティ社CTOに聞く
・ソース・コードに潜むバグを発見、Coverity社の静的解析ツール
・並列ソフトウエア開発の問題、仮想環境がデバッグを改善
・仮想環境を利用してデバッグ、バック・トレースも可能に