アプリのバージョンアップで変更履歴を見ると、ときどき「メモリリーク修正」みたいなものがある。
メモリリークなんて、最初からがんばればよかろうに・・・と若い頃は思っていた。
というよりも、組込みソフトの場合、動的にメモリを取らず、静的にメモリを確保することが多いので、気にしていなかったのかもしれない。
静的に取ることが多いのは、
- そもそも動的メモリがない（mallocがないなど）
- 同時に動的メモリを確保して足りなくなることがあってはいけないので、最初から確保しておく
などという理由なんじゃないかと思う。
私の場合は、mallocが無いので、そもそも動的メモリという選択肢がない、という場合が多かった。
まあ、OSが載ることもほとんど無いしね。
ここ半年くらい、PCのLinuxでソフトを書いている。
もちろん、mallocなんか普通に使える。
同時にメモリを確保して足りなくなるなんてことが、ほぼない。
そもそも、PC Linuxで作ることを前提にしているので、リソースは十分にあるものという仕様になっている。
であれば、動的メモリを使わない必然性がなくなってしまう。
なんとなく気付いたかもしれないが、私は動的メモリが苦手なのだ・・・。
なるべくがんばったので、やったことを書いておこう。
前提として、C言語のみ、だ。
malloc系のAPIとfree()をマクロにした
出落ち感があるが、これに尽きる。
マクロにしておくと、例えばmallocしたところを__FILE__と__LINE__で出すことができる。
inlineにしていても、これはできないと思うのだ。
static変数を使って、通過したカウンタなんかを付けるのもやる。
malloc系でインクリメントして、free()でデクリメント。
全部解放していると思っているところでカウント値を見れば、簡易的なチェックには使える。
valgrindする
してたんだけどねぇ。。。
とにかく、終了するアプリじゃないので、valgrind結果を見るタイミングがない。
unit testのときには使えるのだけど、mallocするタイミングとfreeするタイミングが別々になることが多くなると、unit testでは漏れが確認できない。
というよりも、アプリが終了しないので、動的にチェックできたとしても、今が解放されているべきなのか、そうでなかったらいくつ確保されているべきなのか、というのは状態によって異なるので、結局ログを全部追わないとわからんかったりする。
デストラクタとかガベッジコレクションのある言語が憎たらしくなるのは、こういうときだ。
しかし、もう2017年も後半になってきた。
実は、私が知っている手段以外によいものがあるかもしれない。
それに、オライリーの「Debug Hacks」から読み直すべきかもしれん。
組込みで使えそうなところ以外は読んでいないからだ。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。