SOLID開発プラットフォームでは、不具合を作り込まない仕組み、不具合をスマートに検出するための様々な仕組みを持っているのが特徴です。これらは、デスクトップソフトウェア開発環境として実績のあるものを、SOLIDが組込みソフトウエア開発環境として初めて利用できるようにしたものです。
不具合を作り込まないようにするには、SOLID-IDEが持っているインテリセンス機能（コーディング支援）や、コンパイラの自動文法チェック機能（コンパイラのバックグラウンド実行により文法エラーを指摘）が有効です。またSOLIDではプログラムの流れを論理的に解析して不具合を検出できる静的解析機能も標準で備えており、簡単な操作だけで利用可能です。
机上検証の後、実際にプログラムを動作させてはじめて現れる不具合の中で、ソフトウエア開発者が意図せず巻き込まれてしまう最も多いものがアドレスバグと称される「間違ったアドレスのメモリへのリード／ライト操作でデータを壊してしまう」ケースです。SOLIDにはこのアドレスバグを自動的に見つけるための実行時バグ検出機能を持っており、うっかりミスなどを効率よく検出しソフトウエアの品質向上に大変有効です。
本書では3回にわたって、SOLIDの実行時バグ検出機能であるアドレスバグの自動検出を詳しく解説していきます。
第一回は、「どんなバグが検出できるのか？」についてご紹介します。第二回は、アドレスバグ自動検出の仕組みについて、第三回ではアドレスバグ検出機能の有効な使い方について、引き続きご紹介予定です。
（全三回分をまとめて読む→ pdf版はこちら）
ソフトウエアの規模が大きくなると、複数メンバーによる分担開発はもちろん、協力会社に委託をして共同開発するというスタイルが当たり前になっています。そんな大規模ソフトウエアの開発で最も困ってしまうのは、「単体テストでは問題無く動作していたが、結合テストで不具合が起きる」というシーンではないでしょうか。
開発対象のソフトウエアの本来機能の仕様やアルゴリズムに関する不具合であれば、仕様に従って論理的に追いかける事が有効ですが、意図せず不当にメモリが書き換わっていたようなアドレスバグの場合は、目の前で起きている不具合現象は分かるものの、その原因となるバグがどこに潜んでいるのかを探すのが大掛かりになってしまいます。
不具合が出ている実機にデバッガを接続し、不具合現象が起きているソースプログラムを見ながら怪しい箇所に片っ端からブレークポイントを張り、break > step in > step out > step over を繰り返しているうちに、不具合の出方が変わってしまう、という辛い「モグラ叩き」を延々と続けた経験をされた方もいらっしゃることとでしょう。
また、アドレスバグとなった動作が実行されたあと、その影響が不具合となって表面化するまで大量のコードが走ってしまうので、実行履歴（トレース）を延々と追いかけなければいけない事もめずらしくはありません。しかもトレース情報をバッファするメモリ容量が有限なので、問題の原因となった実行箇所は既にその後の履歴に上書きされてしまい、結局肝心な問題箇所が判らない事もあります。
意図せずにうっかり作り込んでしまったアドレスバグは、作り込んでしまった側が「見つけてもらうのを待つ」しかないのでしょうか？
SOLIDのアドレスバグの自動検出機能は、従来のデバッグ手法のような、バグのありそうなところに当たりをつけてブレークポイントを張って、トレース履歴を解析したり、コツコツと step 実行をしながらバグを追い込んでいくという手法ではありません。SOLID環境下でビルド～デバッグを行う一連の開発作業の中で、SOLIDがバグ検出のためのランタイムを生成し、それを実行するだけで自動検出機能を簡単に利用できるのが大きな特徴です。
またSOLIDがアドレスバグを検出するのは、不当アクセスが発生した瞬間です。たとえそのバグが他のプログラムに何の影響を与えていなかったとしてもバグが検出できるため、単体テストの段階でも効果的に利用できます。
以下にSOLIDが自動検出できるアドレスバグの例をご紹介します。