最後になりますが、SOLIDの実行時アドレスバグ自動検出機能を使って便利にデバッグができた体験談を紹介いたします。
あるSoCを搭載したボードに、外部から提供された画像処理ライブラリのポーティング作業をすることになりました。画像処理ライブラリはバイナリだけの提供で、ソースコード無しという条件でした。
SOLID環境でライブラリのポーティング後にデバッガを接続してプログラムを実行させたところ、プログラムがブレークし、SOLID IDEがスタックオーバーフローを表示しました（図3-5 オーバーフローしたタスクのスタック使用量が赤で表示されるため、すぐに気付くことができました)。
図3-5 スタックオーバーフロー発生時のデバッガ画面
RTOSビューアでスタックオーバーフローを起こしたタスクを確認し、そのタスクのスタックサイズを2倍に設定して再試行してみたところ（ソースコードが無くてもスタックサイズは変更可能です）今度はエラーの発生はなく、無事にポーティング作業が終了しました。
このように、デバッグ担当者が意図的にブレークポイントを張るという操作は行わず、ソースコードも無い状態でしたが、即座に不具合箇所が見つかり対策する事が出来ました。
なおこの例では、テスト用の機能を有効にしてビルドした場合に、通常時よりも多くのスタックメモリを消費する機能が動作するのが直接的な原因でした。すなわちコードに本質的な問題があったわけでなく、いわば設定ミスのようなものでした。
従来のRTOSでの開発においては、このようなトラブルのときには、スタックを破壊してから暴走するなり不正な動作になってしまうので、原因を一瞬で突き止める、ということはなかなかできませんでした。過去の経験で「スタックサイズが原因かも？」と思うことができれば早期解決は可能ですが、そうでない場合には、どこまで正しく動作したか、ということをブレークポイント設定したり、またログを仕込んだりするところからデバッグを始めなければなりません。設定ミスであっても通常のデバッグ並みに多くの時間を消費することもあるのです。しかしSOLIDのスタックオーバーフロー自動検出機能では、このようにスタックが足りなくなった状況を即座にユーザーに通知するので、無駄な時間を消費することがありません。
従来のデバッグ手法では、正当なメモリの利用者が実害を受けてから不具合現象がわかり、そこから真犯人を探す旅が始まるわけですが、SOLIDの実行時アドレスバグ自動検出機能を活用することで、不当アクセスが起きた瞬間に現行犯で犯人を逮捕できるのです。本書を通して、皆様にもその違いの大きさがお分かりいただけたことと思います。
（終）