システムテストの必須項目（２）・メモリ以外の動的資源リークテスト
組み込みソフトでリークするのはメモリだけではありません
リークの危険があるのは OS の提供する動的メモリだけではありません。アプリケーション内に準備した動的な管理テーブルのエントリや OSの提供する通信ソケットやポート番号等も、動的メモリと同じような動的資源なのでリークする危険性を抱えています。これらの動的資源のリークを費い起すバグも、メモリリークびバグと同じ様にとても厄介な時限爆弾バグです。この記事では、動的メモリ以外の動的資源のリークテストについて紹介します。
見落とし勝ちな動的管理テーブルのエントリリーク
他のソフトからの処理を受け付けるサーバ機能を持ってるアプリソフトの場合には、内部に管理テーブルを持っていてその管理テーブルに他のソフトからの処理要求を登録するような、動的な管理テーブルの機能を実装する事もあります。例えば以下のような機能を実装しているサーバソフトＡを想定してみて下さい。
- サーバソフトＡは複数のユーザソフトからの処理要求を受け付け、順番に処理を実施して応答を返す
- サーバソフトＡはソフトＢからの処理要求を受けると内部の管理テーブルにソフトＢを登録する
- サーバソフトＡはソフトＢからの処理要求を実行し終えると結果をソフトＢに返す
- サーバソフトＡは結果をソフトＢに返した後で管理テーブルからソフトＢの登録を削除する
2項で内部の管理テーブルにソフトＢを登録して4項では管理テーブルからソフトＢの登録を削除します。これは、管理テーブルへの登録/削除の操作があるので管理テ―ブルのエントリが動的資源として動作しています。そうすると、例えばサーバＡでのソフトＢの処理でエラーＣが起きて、ソフトＢにエラー応答を返すような異常処理の中で、管理テーブルからソフトＢの登録の削除を忘れていると、エラーＣが起きるごとに管理テーブルの中にソフトＢの登録のゴミが溜まっていきます。これは管理テーブルのエントリがリークしている状態です。管理テ―ブルのエントリリークが進んで全ての管理テーブルエントリがゴミで埋まってしまうと、サーバソフトＡはそれ以降の処理要求を受け付けられなくなります。
管理テーブルとう表現をしましたが、サーバ機能を実装する時に複数の処理を受け付ける仕組みがあれば、内部には必ず複数の処理を管理するデータ構造が必要になります。それは管理テーブルだったり処理待ちキューだったりと、データ構造は色々です。データ構造は色々ですが、登録と削除という処理があればそれは動的資源でリークの危険性があるので、リークテストを行っておく必要があります。
この場合の動的資源のリークテストは割と簡単です。ソフト内部に準備する動的資源の量の初期値が判っているので、ソフトに対して動的資源を使うような様々な動作を行った後の、動的資源の残量が減っていない事を確認すればリークの有無が確認できます。
アプリで準備した動的メモリがあれば要注意
最近の組み込み系ソフトでは内部にサーバ機能を持つソフト構造も増えてきました。サーバ機能を持つソフトの場合には、上記のように他ソフトからの処理要求を管理するための管理情報以外にも、内部での処理のために動的資源を実装する事も多いです。
例えば、上記のサーバソフトＡを例にすると、内部の処理に使うためのデータバッファ領域として可変長の領域が必要だっとすると、最大サイズＸ最大処理件数のメモリを静的に獲得すると膨大なサイズになるので、必要に応じて内部のメモリを使い回す仕組みを実装する事になります。
この、必要に応じて内部のメモリを使い回すというのは、結局のところ内部に実装した専用の動的メモリと同じで、獲得/解放の処理が存在します。と言う事は、解放処理を漏らしてしまうとこのメモリのリークが起きる事になりますので、このような内部処理で使っている動的資源についても、リークテストが必要です。
ＯＳの提供する動的資源としてソケットも注意
OSの提供する動的資源は動的メモリ以外にもあり、稀にですがこれらの動的資源のリークが起きる事があります。比較的よくあるのが、ソフト間の通信で使うソケットやポート番号のリークです。 グータラ親父の経験では、製品の異常処理の中でのソケットの Close 処理漏れによって、市場でソケット枯渇による機能停止が起きた事もありました。 ソフトの構造上は、ソケットと同時にポート番号もリークしていたのですが、この時はシステムの構成上ソケットのほうが先に枯渇して機能停止が起きていいました。
ソケットが枯渇して使えなくなったのが、リモートメンテナンス用の通信機能だったので回復手段がなくとても困りました。ソケット枯渇の発生条件は、エラーが多発する通信環境でのリモートメンテナンス機能へのログインの繰り返しなのですが、リリース前の社内テストではエラーの無い通信環境での動作加速テストしかしていなかったので、このソケットリークを検出できていませんでした。
全ての動的資源に対してそれぞれのリークテストが必要
動的資源のリークは、リークの発生する条件が繰り返される事で徐々に資源の残量が減っていき、ある時に残量がゼロになって初めてソフトの動作不良として見えてきます。そのため、出荷前のテストでは、資源リークの検出を目的としてリークテストをしっかりと実施しておかないと、潜在する動的資源のリークバグを見落としてしまう事になります。
動的資源のリークテストでは、リークの可能性がある動的資源の洗い出しとリークを起こる処理の加速方法の２つが重要になってくるので、しっかりと検討しましょう。
リークテストの次ぎはタイマやカウンタのロールオーバーテストです
組み込み系ソフトに潜む時限爆弾バグの検出のために、メモリや動的資源のリークテストの次ぎに重要なのが、タイマやカウンタのロールオーバーテストです。これについては、次の記事で紹介しましょう。