バグ #198
完了
ダークマターの討伐
説明
長時間起動していると、際限なくメモリを消費していく。
ファイル
toshi_a 初音 さんがほぼ13年前に更新
Gtk::ListStore#flags を呼びだすと、 Gtk::TreeModel::ITERS_PERSIST がセットされている。どうやらこれがセットされていると Gtk::TreeIter が開放されないらしいんだけどもう眠いしまた今度ね
toshi_a 初音 さんがほぼ13年前に更新
Gtk::TreeIterがGCされないので、ツリーごと殺すようにしてみた、これはひどい。
それはまた本家にフィードバックするとして、こんどはArrayが妙に増えるようになったみたいなので調べる
toshi_a 初音 さんが12年以上前に更新
Gtk::TreeIterはとりあえずはましになってる。これ以上手を付けられない気がするので、先に他のところをやっつける。
一部Procオブジェクトが線形に増えているので、それを削減する（クロージャのスコープに巻き込まれることがあるため）。
toshi_a 初音 さんが12年以上前に更新
- ファイル out2.png out2.png を追加
- ファイル miraclepainter.png miraclepainter.png を追加
10時半以降のデータはmikutterの限界ｒｙ
Gdk::MiraclePainterが一切解放されていなかったので、 r632 で少し修正を加えた。
これで、コメント9で問題にしたcairo_subparts_voterのProcオブジェクトはMiraclePainterと共に解放されるようになった。
ただし、この版では、TLのリフレッシュ時にはMiraclePinterが解放されるようになったようだが、依然としてインスタンス数は添付のmiraclepainter.pngの通り増加していっている。タイムラインから溢れて削除する処理について、もう一度見直す。
toshi_a 初音 さんが11年以上前に更新
- ファイル memory_profiler.rb を追加
- ファイル mikutter-memory.gtk_liststore.png mikutter-memory.gtk_liststore.png を追加
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分程度かかっていること。サンプルを取る前に毎回明示的にガベージコレクタを呼んでいるので、この間どこかで参照が保持されていると考えられる。
toshi_a 初音 さんがほぼ10年前に更新
- ステータス を 実装待ち から 終了 に変更
このチケットはある程度の成果を出したがまだ不十分です。しかし目標が明確でないので、今後は具体的な問題が分かり次第トピック毎にチケットを作成するようにします。