前回までは、Windows CEを採用した製品開発で得られるメリットと、忘れてはならない注意点について説明してきました。今回より、実際に起きやすい障害を例に、具体的なツールを用いたデバッグ手法について解説していきます。
今回のテーマは、すぐに現象が現れない場合にその原因が見つけにくく、お客様からご相談を受けることが最も多い障害、メモリリークについてです。


メモリリークが引き起こす現象
　組込み製品開発における、厄介で原因を究明しにくい障害の1つがメモリリークです。
実装メモリが少なく、長期間の連続安定動作が求められる組込み製品では、わずかなメモリリークでもそれが蓄積され、パフォーマンスの低下やハングアップなど、さまざまな現象を引き起こします。


メモリリークはなぜ厄介か
　メモリリークを発生させている原因のプログラムとは全く別のプログラムで影響が発現することがあります。メモリ確保と解放が異なるプロセスで行なわれるような複雑なプログラムでは、メモリリークの原因箇所を突き止めることが非常に困難です。
　また、組込み製品を問わず、大規模ソフトウェアでは、ドライバ、ミドルウェア、アプリケーションなどの各プログラムが全て把握されきっていない、またはソースコードが存在しないなどの理由で、メモリリークの疑いがあってもソースコードを確認できないケースもあります。


メモリリークのデバッグ手法
　このような厄介な障害を効率よくデバッグするには、まず、製品で障害が発生した状況、挙動を良く見極め、現象の切り分けを行い、原因を絞り込んでいくことが大切です。
　長時間運用時にメモリ不足の警告が表示されたり、パフォーマンスが低下したり、ハングアップ現象が起る。これらの現象が製品をリセットすることにより回復するようであればメモリリークを疑い、まずはメモリリークに的を絞ってその原因を追究します。
　その製品が開発PCとデバッグ接続可能であれば、Platform Builderのパフォーマンスモニタ機能を使用してシステム稼働中のメモリ残容量の遷移を確認し、メモリリークがどの程度の頻度で発生しているかどうかを確認することができます。
　メモリリークの発生が確認できたら、どのプロセスでメモリリークが発生しているのかを特定するために、メモリリークの状況を確認しながらシステム構成から順にプロセスを除外していき、原因プロセスを絞り込んでいきます。
　Windows Embedded CEの開発環境では、Application VerifierやLMemDebugなどのメモリリークを解析する機能を持つデバッグツールが提供されているので、これらを活用することも非常に有効です。


現状の問題と課題
　一般的なメモリリークのデバッグ手法を説明しましたが、ここにはいくつかの問題と課題があります。
　デバッグ環境によっては、ホストPCと接続できないためにPlatform Builderの機能が使えないことや、疑わしいプロセスが絞り込めてもソースコードがないために原因の確認ができないこともあります。
　原因絞込みの過程で「構成変更→再ビルド」を繰り返すことにより膨大な時間を費やすこともありますし、疑わしいドライバがあっても構成から外して検証を行えないこともあります。
　Application VerifierやLMemDebugなどのツールを利用する解析では、「使いこなすのに時間がかかる」、などの理由ですぐに使えないことや、「OSがバージョンアップしたら使えなくなった」と言うこともあります。（LMemDebugはCE6.0では対応されなくなりました。）
　また、自作のデバッグツールを作成して使用されているケースも良く耳にしますが、そのメンテナンスにはみなさん苦労されているようです。
　以上のことより、デバッグ環境による制限やデバッグ作業の効率化などをどう解決するかが現状の課題と言えます。


次回のテーマ
　次回は、メモリリークと同様に原因を究明しにくい、再現性が乏しい障害のデバッグ手法について解説します。