ふぅ。
メモリリークと騒いでいる現場では、メモリリークの定義自体が曖昧です。
昔からメモリリークというとかつてプログラミング関連MLや掲示板のフレームの原因のトップ3に鎮座したような話題なのです。
ちょっとしたウンチクや、tipsで解決できる問題ではありません。
例：
・プロセスがmallocしたメモリは、プロセス終了時にfreeされるから解放しなくても良い
というようなどうでもいい主張に始まり、
・GCがあるJavaやC#でもメモリリークは存在する
というもっとどうでもいい話。
・真のメモリリークとはGDIオブジェクトのリークのことである
という珍説。派生したものに
・巷のメモリリークのほとんどは、カーネルオブジェクトの解放漏れが原因(SelectObject忘れだけでも)
というコペルニクス的発見。
関連して必ずでてくる話題に、
・スタックが深すぎてメモリを食いつぶしている
# 32ビットWindowsではスタックは自動伸長することに注意
・スマートポインタ/オートポインタを使え
なお、同一プロセス内の各スレッドが別々のスタックを持っていると気付かない人も多数います。きっとファイバかマイクロスレッドがスレッドだと思い込んでいる人たちです。
まじないじみた迷信も多数あります
・auto変数が"漏れる"
# どういう仕組み？longjump(笑
仮想メモリと物理メモリの説明からはじめると、説明が終わる頃にはプロジェクトが終了しています。
ですが、そこを乗り越えないとページ単位のコミットとか、小さいメモリブロックのハンドリングの効率が良くない原因などについて決して理解できません。いわんやメモリの断片化なんて。
#2の累乗サイズでreallocする理由とか。
そうかといって、マッチ箱系の組み込み屋のベテランさんのように、
ブラックボックスのAPIで確保したメモリブロックなんて信用ならない
というあまりにも低い視点からスタートしたのでは、本来解くべき問題に到達する前にヒューマンリソースが枯渇してしまいます。
ここでは特効薬を示せませんが、北極星の向きはお知らせすることができます。
・とにかく測定手段を探すこと
これに尽きます。測定できないものは手の出しようがありません。
体重計なしでダイエットできないのと同じです。
測定さえ出来れば、稼働中にモニタリングすることもできます。
危険水域に達したら警告を発することもできます。
failmallocのようなものでテストしても良いでしょうが、組み込み系では、稼働中にメモリ不足＝設計ミス確定ですから、あまり役には立たないでしょう。
設計時に必要なメモリが見積もれないなんて、製品開発ではありえない話です。
これもきっとベストエフォート至上主義の弊害なのでしょう。暗い時代はまだまだ続きそうです。