LeakCanaryでメモリリークを検出する - Qiita
Squareがメモリリークを検出するライブラリ square/leakcanary を公開したので、さっそく使ってみたらすごく便利だった話です。 A small leak will sink a great ship Piwaiが書いたLeakCanaryの記事がこちらです。 LeakCanary: Detect all memory leaks! 要約すると、 Squareではビットマップキャッシュに顧客の署名を書いていたが、端末の画面のサイズ分のメモリを確保するので、署名をするときにクラッシュすることがあり、それがOOMの大半を占めていた。 Bitmap.Configを変更したり、OOMをキャッチしてGCを走らせたりしたが、問題の解決には至らなかった。 我々は間違ったアプローチを取っていたことに気が付いた。ビットマップの大きさではなくメモリリークが根本的な原因だったのだ。 通常であれば
メモリーリーク調査でわかったことをメモしておこう - いつもどこかでデスマーチ♪
読み直してみると、読みたくなくなる記事だなｗｗｗｗ なので端的に… 1. Global Flagsを使って設定 2. WinDbgを実行 3. !heap -stat -h 0 4. プロセス実行 5. !heap -stat -h 0 6. 1.と3.の結果を比較 7.!heap -flt s サイズ 8.!heap -p -a アドレス この8手順を踏めば、メモリリークの(おそらく)原因の場所が突き止められます。 さて読みにくい本編です。 外部DLLを使っているので、.NETでおきているのか、外部DLLでおきているのかさっぱり解らなかったが このツールを使ってみると、なんとなーくみえてきた。 で、その使い方と注意事項をまとめてみました。 使ったツール： WinDbg Global Flags ダウンロードファイル：(2012年5月現在) winsdk_web.exe URL：http:
メモリリークとは何か - kuenishi's blog
メモリリークに悩まされている技術者は多いだろう。メモリリークが嫌でGCという技術が開発されたといっても過言ではないし、歴史的にはC++からJavaへシフトが起きた大きな理由のひとつといっていい。Unix系の簡単な定義でいえば、ヒープ領域を指すポインタ（アドレス）をロストしてしまえばそのメモリはもう漏れたといってよい。たとえばこういったコードだ。 struct { int i; char c; } spam; int main(){ void* p; int i; for(i=0; i<1024; ++i){ p = malloc(sizeof(struct spam)); } pause(); } このコードではpause(3)の時点で約5KBのメモリが漏れている。free(3)を使えばメモリをOSに返却できるが、アドレスが分からないので返却できない。 ところが、ここでいいたいのは、メモリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
