![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
valgrindのFAQ日本語訳 http://srad.jp/~oku/journal/346649/ valgrindの違う使い方 http://blog.livedoor.jp/sonots/archives/39965025.html mtrace（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 "definitely lost":: メモリリークしてるから, とにかく直せ！ "indirectly lost":: ポインタベースの構造 (ツリーやリストなど) があったとき, そのルートノードが開放されていない ("definitely lost") 場合, 子ノードは全て "indirectly lost" となる. ルートノードなどの"definitely lost" を修正すれば, この "indirectly lost" も消える. "possibly lost":: ポインタをうまいこといじくり回さない限り, メモリリークしてしまう. "still reachable":: おそらく問題無し. 開放すべきメモリを開放していない部分はあるが, これはごく一般的で利にかなっている. この警告を表示したくない場合 --show-reachable=yes のオプションはつけないこと. メモリリークが以下のような状況で起こった場合、問題は特に深刻になる。 プログラムが長期間動き続けるとき。サーバーサイドアプリケーションや組み込みシステムは年単位で稼働し続けることもある。 共有メモリのような、確保したまま終了することが許されるメモリ領域をプログラムが使っているとき。 ゲームや動画を扱うプログラムのように、メモリの確保・解放を頻繁に行うとき。 OSやシステムそのものがメモリリークを起こすとき。 組み込みシステムやポータブル機のように、メモリの絶対量が少ないとき。 AmigaOSのように、プロセスが終了してもメモリが自動的に解放されないOSを利用しているとき。メモリリークから回復する手段は再起動しかない。 valgrind --leak-check=full --leak-resolution=high --show-reachable=yes ./memleak http://etc2myday.jugem.jp/?eid=205 Conditional jump or move depends on uninitialised value(s) 未初期化の変数を使った http://goyoki.hatenablog.com/entry/2014/03/31/003736 有名なメモリリーク http://www.geocities.jp/gmicro300/doc/valgrind.html Helgrind，マルチスレッドのvalgrind http://d.hatena.ne.jp/tomohikoseven/20121124/1353751205 Valgrindの超いい解説．配列外参照なのに検出されないところの解説もある http://etc2myday.jugem.jp/?eid=205 |
