バグ #198
closedダークマターの討伐
Added by toshi_a 初音 over 13 years ago. Updated almost 3 years ago.
Description
長時間起動していると、際限なくメモリを消費していく。
Files
proc-spread.png (128 KB) proc-spread.png | Procオブジェクトの生成された場所ごとの個数 | toshi_a 初音, 2011-05-30 01:31 | |
memory.png (169 KB) memory.png | オブジェクト別の個数 | toshi_a 初音, 2011-05-30 01:31 | |
iter.png (118 KB) iter.png | Gtk::TreeIterが回収されない | toshi_a 初音, 2011-06-04 12:33 | |
iter.png (50.2 KB) iter.png | Gtk::TreeIterを節約した。短時間しか測ってないけどずいぶんマシでしょう | toshi_a 初音, 2011-06-04 12:33 | |
memory.png (155 KB) memory.png | オブジェクト別個数。やっぱりTreeIterだな | toshi_a 初音, 2011-09-29 23:59 | |
out.png (263 KB) out.png | 2012/1/5の、trunkでの計測結果。10時前から後は役に立たないが、Procのグラフが段になってるのが気になる | toshi_a 初音, 2012-01-06 01:27 | |
out2.png (91 KB) out2.png | toshi_a 初音, 2012-01-07 05:42 | ||
miraclepainter.png (17.5 KB) miraclepainter.png | toshi_a 初音, 2012-01-07 05:42 | ||
mikutter-memory.gtk_liststore.png (79 KB) mikutter-memory.gtk_liststore.png | home_timelineだけをインストールした状態での、Gtk::ListStore(Model)の数の変化 | toshi_a 初音, 2012-11-30 23:12 | |
mikutter-memory.png (146 KB) mikutter-memory.png | home_timelineだけをインストールした状態での、各クラスのインスタンス数の変化(ベスト10) | toshi_a 初音, 2012-11-30 23:15 |
Updated by toshi_a 初音 over 13 years ago
Gtk::TreeIterが全くGCされない。おそらくRubyGtkのバグかと思われる。
これはバグ報告するにしても、ただちにメモリリークを直せるわけではないので、値の参照の時にはGtk::TreeIterをアロケートしないようにした。
Updated by toshi_a 初音 over 13 years ago
Gtk::ListStore#flags を呼びだすと、 Gtk::TreeModel::ITERS_PERSIST がセットされている。どうやらこれがセットされていると Gtk::TreeIter が開放されないらしいんだけどもう眠いしまた今度ね
Updated by toshi_a 初音 over 13 years ago
Gtk::TreeIterがGCされないので、ツリーごと殺すようにしてみた、これはひどい。
それはまた本家にフィードバックするとして、こんどはArrayが妙に増えるようになったみたいなので調べる
Updated by toshi_a 初音 over 13 years ago
- Subject changed from メモリリークへの対応 to ダークマターの討伐
Updated by toshi_a 初音 almost 13 years ago
Gtk::TreeIterはとりあえずはましになってる。これ以上手を付けられない気がするので、先に他のところをやっつける。
一部Procオブジェクトが線形に増えているので、それを削減する(クロージャのスコープに巻き込まれることがあるため)。
Updated by toshi_a 初音 almost 13 years ago
10時以降のデータは、mikutterのメモリ使用量的に限界に達したと思われるので、あまり意味のある値ではない。
下のグラフ(Procの統計)で、sub_parts_voter.rbのinitialize()内で作られたProcが定期的に段を作るように増えて行っているのは、Gtk::TreeIterのメモリリーク対策で強制的にリストビューを破棄しているところで、そのProcが解放されずに残っているということかもしれない。
Updated by toshi_a 初音 almost 13 years ago
- File out2.png out2.png added
- File miraclepainter.png miraclepainter.png added
10時半以降のデータはmikutterの限界ry
Gdk::MiraclePainterが一切解放されていなかったので、 r632 で少し修正を加えた。
これで、コメント9で問題にしたcairo_subparts_voterのProcオブジェクトはMiraclePainterと共に解放されるようになった。
ただし、この版では、TLのリフレッシュ時にはMiraclePinterが解放されるようになったようだが、依然としてインスタンス数は添付のmiraclepainter.pngの通り増加していっている。タイムラインから溢れて削除する処理について、もう一度見直す。
Updated by toshi_a 初音 almost 12 years ago
- File memory_profiler.rb added
- File mikutter-memory.gtk_liststore.png mikutter-memory.gtk_liststore.png added
home_timeline, rest, streaming, gui, gtkの5プラグインだけを入れた状態でテストしてみたところ、やはりTreeIterがかなりメモリリークしている(RubyGtk1.1.5)。起動中のインスタンスを調べたところ、Gtk::TimeLineは1つ、Gtk::TimeLine::InnerTL(view)とGtk::ListStore(そのModel)はそれぞれ10個あり、1つを除いてはすべて破棄済み(destroyed? #=>true)だった。Gtk::ListStoreの数もグラフにプロットしてみたところ、どうも定期的にInnerTLを破棄する処理がされたあと、InnerTLがガベージコレクトされずに残ることがあるらしい。
グラフを見る限り、正しくInnerTLが破棄されればTreeIterも開放されるようで、実際二つのグラフは形が非常に似通っているため、InnerTLへの参照を切ることが出来れば、劇的な改善が期待できる。
他にこのグラフの気になる点としては、Gtk::ListStoreの開放に長くて15分程度かかっていること。サンプルを取る前に毎回明示的にガベージコレクタを呼んでいるので、この間どこかで参照が保持されていると考えられる。
Updated by toshi_a 初音 almost 12 years ago
- File mikutter-memory.png mikutter-memory.png added
添付ファイル間違えた
Updated by toshi_a 初音 over 10 years ago
- Status changed from 実装待ち to 終了
このチケットはある程度の成果を出したがまだ不十分です。しかし目標が明確でないので、今後は具体的な問題が分かり次第トピック毎にチケットを作成するようにします。