[[C++]] *概要 [#tde286d2] -動的メモリチェッカ *参考 [#jd594a71] -[[valgrindのFAQ日本語訳>http://srad.jp/~oku/journal/346649/]] -valgrindの違う使い方 --[[mtrace>http://blog.livedoor.jp/sonots/archives/39965025.html]](mtraceの便利なところは、ソース内でどこからどこの間でリークを調べたいかを指定できる点です) --http://blogs.itmedia.co.jp/komata/2009/10/mtrace-valgrind.html -[[valgrindはfull, memory_checkで何倍くらい遅いの??>http://valgrind.org/docs/manual/faq.html#faq.deflost]] *基本的な使い方 [#z6276be8] -コマンド --ふつう ---valgrind ./memleak --[[フルオプション>http://etc2myday.jugem.jp/?eid=205]] ---valgrind --leak-check=full --leak-resolution=high --show-reachable=yes ./memleak -見方 --"definitely lost":: ---メモリリークしてるから, とにかく直せ! --"indirectly lost":: ---ポインタベースの構造 (ツリーやリストなど) があったとき, そのルートノードが開放されていない ("definitely lost") 場合, 子ノードは全て "indirectly lost" となる. ルートノードなどの''"definitely lost" を修正すれば, この "indirectly lost" も消える.'' --"possibly lost":: ---ポインタをうまいこといじくり回さない限り, メモリリークしてしまう.だいたいメモリリークしてる --"still reachable":: ---おそらく問題無し. 開放すべきメモリを開放していない部分はあるが, これはごく一般的で利にかなっている. この警告を表示したくない場合 --show-reachable=yes のオプションはつけないこと. -よくみるやつ --Conditional jump or move depends on uninitialised value(s) ---未初期化の変数を使った。 ---これを直すと、突然変な値になる再現性のないバグを防げる。 --Invalid read/write ---配列外参照。 ---これを直すと突然落ちたり、突然変な値になる再現性のないバグを防げる。 *使いどころ [#w9ede600] -メモリリークが以下のような状況で起こった場合、問題は特に深刻になる。 --プログラムが長期間動き続けるとき。サーバーサイドアプリケーションや組み込みシステムは年単位で稼働し続けることもある。 --共有メモリのような、確保したまま終了することが許されるメモリ領域をプログラムが使っているとき。 --ゲームや動画を扱うプログラムのように、メモリの確保・解放を頻繁に行うとき。 --OSやシステムそのものがメモリリークを起こすとき。 --組み込みシステムやポータブル機のように、メモリの絶対量が少ないとき。 --AmigaOSのように、プロセスが終了してもメモリが自動的に解放されないOSを利用しているとき。メモリリークから回復する手段は再起動しかない。 *まとまってないもの [#d568c456] -http://goyoki.hatenablog.com/entry/2014/03/31/003736 -[[有名なメモリリーク>http://www.geocities.jp/gmicro300/doc/valgrind.html]] -[[Helgrind>http://d.hatena.ne.jp/tomohikoseven/20121124/1353751205]],マルチスレッドのvalgrind -Valgrindの超いい解説.配列外参照なのに検出されないところの解説もある --http://etc2myday.jugem.jp/?eid=205 |