PR

 メモリーリークを生じさせるバグは、プログラムのソースコードを静的に検査するだけでは発見が難しい。効率的に発見するには、プログラムを実際に動作させてメモリーの使用状況を監視する動的検査が不可欠である。動的検査ツールの一例が、グーグルが開発した「Address Sanitizer」。同ツールを利用すると、スタックバッファーオーバーフローをはじめとした、様々なメモリー関連バグを動的に発見できる(図3)。

図3●動的検査ツール「Address Sanitizer」の動作例
図3●動的検査ツール「Address Sanitizer」の動作例
GCC(GNU Compiler Collection)に実装されているAddress Sanitizer機能をLinux環境で使った例。同機能を組み込んでビルドしたサンプルコードを実行すると、確保したバッファーを超えた書き込みをしたことが実行時に検知された。
[画像のクリックで拡大表示]

 しかし従来のAndroidは、Address Sanitizerのような動的検査ツールを利用しづらい面があった。動的検査ツールでは一般的に、プログラムが使用するライブラリー関数をチェック用コード付きの関数に実行時に置き換えることで検査を実現する。関数を置き換えるには、動的リンカーに対して、検査ツール付属の特殊なライブラリーを優先的に探索してリンクするように指示する必要がある。

 従来のAndroidの動的リンカーでも、LD_PRELOADという環境変数で指示したライブラリーを優先探索してリンクさせることはできた。しかし、この方法は利用できないケースも多く、その場合は動的検査が難しかった。

 Android Mの動的リンカーには、LD_PRELOADを使う方法以外にライブラリーを優先探索してリンクする方法が追加される。これによって動的検査ツールを利用しやすくなる。

 また、ライブラリーの格納位置を示すパスや「soname」と呼ばれる別名を正しく取り扱えるようにする改良も加えられる。従来の動的リンカーは、ファイル名が同じライブラリーが複数あった場合、それらの格納位置(パス)が違っていてもそれぞれを区別できなかった。そのため、本来使用すべきではないライブラリーが意図せずに使用されるケースがあった。Android M以降の動的リンカーではパスを区別できるようになり、そうした問題は生じなくなる。一方、従来のルーズな動作によってかろうじて動作していたプログラムは、パスを区別できるようになったことで動作しなくなる恐れもある。