DebugHacks ネタ – メモリリーク退治

前回のエントリで Debug Hacks Conference 2009 の参加報告 (?) を書きましたが、会場で著者のよしおかさんが「参加した人はブログ等で自分のDebugネタを書いてみんなで共有しよう」とおっしゃっていたので、私のDebugネタをちょっと書いてみます。

以前、ダウンが許されないサーバプログラムで数日間稼働させていると、僅かずつながらもメモリがリークしていくという現象があり非常に困りました。その時のHackです。

Hackその1  mallocカウンタを用意

malloc, free をマクロ定義して独自のmalloc, free で置き換えます。その独自 malloc, free でカウンタの増減を行います。そのカウンタは共有メモリ上に置いておくことでプログラム外から参照できるようにしていました。(コードは雰囲気で、未検証です)

/* 全てのソースがincludeしているヘッダに以下を記述 */
#define malloc(size) __my_malloc(size)
#define free(ptr) __my_free(ptr)
/* 置き換えられるmalloc */
#undef malloc
#undef free
void *__my_malloc(size_t size)
{
void *ptr;
ptr = malloc(size);
if(ptr)
_malloc_count++;
return ptr;
}

void __my_free(void *ptr)
{
free(ptr);
_malloc_count--;
}

これで malloc カウンタを見るとリークが発生しているかどうかが分かります。

ただし、ソフトウェアに定常状態があって、定常状態は常に同じmalloc数の場合でしか使えません。状況に応じてメモリ確保の状況が変わるとダメですね。あと、ライブラリ内でmallocしているようなものはカウントできない欠点もあります。

この方法は、リークの事実は分かっても特定するだけの情報がないので、「リークがない」という事実を確認するには使えますが、リークを潰す目的には使えません。

Hackその2  malloc領域にデバッグ情報を埋め込む

これは比較的メモリに余裕があるときにしか使えないのですが、Hackその1に関連して、mallocをフックした時に実際に要求された領域より+α を余分にmallocしておき、余剰部分にメモリ確保時の状況を書き込んでおくことで、後でリークを検出した時にトレース出来るようにしました。(以下未検証コード)

/* 全てのソースがincludeしているヘッダに以下を記述 */
#define malloc(size) __my_malloc(size, __func__, __LINE__)
#define free(ptr) __my_free(ptr, __func__, __LINE__)
struct malloc_debug_header {
int magic;
const char *func;
int line;
int size;
void *caller;
};
/* 置き換えられるmalloc */
#undef malloc
#undef free
void *__my_malloc(size_t size, const char *func, int line)
{
void *ptr;
struct malloc_debug_header *hdr;
ptr = malloc(size + sizeof(struct malloc_debug_header)); /* 余分にmalloc */
if(!ptr)
return ptr;
_malloc_count++;

hdr = ptr;
hdr->magic = 0xbf8129de; /* magic バイナリに出てこなそうな数値を指定 */
hdr->func = func;
hdr->line = line;
hdr->size = size;
hdr->caller = __builtin_return_address(1);
return ptr + sizeof(struct malloc_debug_header); /* offset を足してreturn */
}

void __my_free(void *ptr)
{
free(ptr - sizeof(struct malloc_debug_header)); /* offset を引いて free */
_malloc_count--;
}

これで各malloc領域にデバッグ情報は埋め込めたけど、じゃぁどうやってそれを読み出すんだよ!と思われるかもしれませんが、それは力技で。

  1. coreダンプさせて、coreファイルからmagicを検索して特定する方法
  2. attatchして、/proc/<PID>/mem をmmapして、そこからmagicを検索する方法

1つ目は、リーク発生後、kill -ABRT <PID> でcoreダンプさせてしまい、coreファイルからmagicナンバーを検索する方法です。

coreファイルはメモリイメージをベタに書き出しているので、gdb で core を開かずとも、バイナリファイルとして magic ナンバーを検索してしまえば、malloc された領域を特定できます。そこからデバッグ情報が書かれているので、line番号やサイズを取得します。

関数名についてはポインタなので、ポインタ値をメモっておいて、gdb でターゲットプログラムを開いて、そのポインタを表示させれば取得できます。

2つ目は、別途プログラムを作る必要がありますが、gdbのようにプロセスにattachして、そのプロセスの /proc/<PID>/mem を mmap することで、ターゲットプログラムのメモリ空間から直接magicナンバーを検索して解析する方法です。この方法では、detach 後、SIGCONTを発行すれば再開するので、プロセスが死なずにすみます。

caller も保存してあるので、おおよそどのルートでmallocされたメモリなのかが分かり、リーク退治に非常に便利でした。

 

今までの私が行ったデバッグの中で一番派手なのが上記の例ですね。後は泥まみれのデバッグばかりです。

私のデバッグスタイルとしては、使えるものを探し(時には作り)、使えるものは全て使ってバグ退治をするという感じですかね。バグを退治するのが目的なので、手段は選びません。

最近は printf デバッグ=悪といった風潮もありますが、printf デバッグも有効な手段である場面も多いと私は思います。私自身結構使いますし、必ずしも悪とは思ってません。その時の状況に応じて使えるものは全て使います。バグ退治に有効ならば。

私の場合、組み込み系の仕事がメインなのですが、i386以外のアーキテクチャではgdbが当てにならない場合が結構あります。マルチスレッドプログラムがgdb上ではうまく動かなかったり、Linuxカーネル起動後はICEなしで開発になったりと、デバッガがまともに使えないケースも結構あるので、デバッガは使えればラッキーくらいな感覚ですね。

なので、あまり手段を選んでられないのです。組み込み系でもスタイリッシュにグラフィカルなデバッガでスイスイデバッグができると楽なんですけどねぇ。組み込み系のようなプアな環境でのデバッグは十数年前からあまり変わってないのかもしれません。


DEBUG HACKS Conference 2009 に参加しました

久しぶりのブログです。今回は zaurus とは関係ないですが。。。

昨日開催された Debug Hacks の発売記念イベント Debug Hacks Conference 2009 に参加してきました。

参加前は本を買うかどうかは立ち読みしてから決めようかと思っていたんですが(^^;)、会場の即売所で買ってしまいました。

オライリーの紙袋 Debug Hacks Tシャツ

会場で本を買ったら DEBUG HACKS Tシャツがもらえました。ネタ以外では着れないですが・・・。
本を入れてくれたオライリーの紙袋がCoolです。

Conference の内容は詳細に書かれている方々がいらっしゃると思うし、動画がいずれニコニコ動画等にアップされると思うので、個人的にためになった部分を。

GDBでリスト表示

まず、gdb のユーザ定義コマンドによるリストの表示。構造体内のnext を辿って最後まで表示してくれるというもの。ユーザ定義コマンド自体は知ってたけど、面倒そうで使ったことなかったんですが、 こういう使い方が出きるなら便利ですね。

コードはメモってないので書けませんが、ユーザ定義コマンド(仮に list_print とする)で1つの構造体を表示するようなコマンドを作っておき、別のユーザ定義コマンドで next を辿って list_print を呼び出すというもの。(説明が下手ですな)

たしかに、ユーザ定義コマンドを作るのに手間がかかりますが、何度も何度もリストを見なければいけない場合には使えそうです。

今までは、

(gdb) p *list_head->next->next->next->next->next->next->next

とか普通に打ってました (汗)

Yuguiさんの発表

私は Ruby は触ったことがないこともあり、失礼ながら Yugui さんを始めて知りました。

まず、プレゼンうまいなーと。スライドの作りも個性的で、話の流れもわかりやすく、ユーモアもあり、とても印象に残りました。

印象に残ったのは、Ruby や Rails ではデバッグであまり苦労していないということ。言語設計やソフト設計が厄介なバグを混入しにくくしているんだなと感心しました。

DbC (Design by Contruct) や BDD (Behavior Driven Development) といった、軽微なバグを初期段階で検出できて、バグを混入しにくい作り方が、地味そうに思えるも非常に有効だと分かりました。

体験談として、DbC を適用して assert 入れまくったらバグがボロボロ出てきて、全て退治したらバグが1つしか残らなかったとおっしゃってました。1つのスキームで数百、数千単位のバグを1つにまで減らせたというのは驚きです。

こういう理論って確かにそうだけど、実際開発には適用が難しくない?とか、本当に手間に対する効果があるの?みたいなことを考えてしまうのですが、バリバリ開発しているハッカーに言われると非常に説得力があります。

いま仕事で開発してるソフトに DbC に倣って assert 入れまくってみようかな。結果がちょっと怖いですが (^^;

サインもらいました

最後に著者の方々にサインをもらってきました。

まだ本は読んでないですが、なかなか勉強になる Conference でした。