バグ #198: ダークマターの討伐 - mikutter - やること

Actions

Copy link

バグ #198

closed

ダークマターの討伐

Added by toshi_a 初音 over 13 years ago. Updated almost 3 years ago.

Status:

終了

Priority:

通常

Assignee:

toshi_a 初音

Target version:

0.0.3

プラグイン名:

ブランチ:

クラッシュする:

Description

長時間起動していると、際限なくメモリを消費していく。

Files

Download all 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

Subtasks 3 (0 open — 3 closed)

Actions

Copy link

Updated by toshi_a 初音 over 13 years ago

File iter.png iter.png added
File iter.png iter.png added
Status changed from 実装待ち to 様子見

Gtk::TreeIterが全くGCされない。おそらくRubyGtkのバグかと思われる。
これはバグ報告するにしても、ただちにメモリリークを直せるわけではないので、値の参照の時にはGtk::TreeIterをアロケートしないようにした。

Actions

Copy link

Updated by toshi_a 初音 over 13 years ago

Gtk::ListStore#flags を呼びだすと、 Gtk::TreeModel::ITERS_PERSIST がセットされている。どうやらこれがセットされていると Gtk::TreeIter が開放されないらしいんだけどもう眠いしまた今度ね

Actions

Copy link

Updated by toshi_a 初音 over 13 years ago

Status changed from 様子見 to 実装待ち

Actions

Copy link

Updated by toshi_a 初音 over 13 years ago

Gtk::TreeIterがGCされないので、ツリーごと殺すようにしてみた、これはひどい。
それはまた本家にフィードバックするとして、こんどはArrayが妙に増えるようになったみたいなので調べる

Actions

Copy link

Updated by toshi_a 初音 about 13 years ago

Subject changed from メモリリークへの対応 to ダークマターの討伐

Actions

Copy link

Updated by toshi_a 初音 about 13 years ago

Target version set to 0.0.3

Actions

Copy link

Updated by toshi_a 初音 about 13 years ago

File memory.png memory.png added

未だ悪さをするのはTreeIterらしい。

Actions

Copy link

Updated by toshi_a 初音 almost 13 years ago

Gtk::TreeIterはとりあえずはましになってる。これ以上手を付けられない気がするので、先に他のところをやっつける。
一部Procオブジェクトが線形に増えているので、それを削減する（クロージャのスコープに巻き込まれることがあるため）。

Actions

Copy link

Updated by toshi_a 初音 almost 13 years ago

File out.png out.png added

10時以降のデータは、mikutterのメモリ使用量的に限界に達したと思われるので、あまり意味のある値ではない。
下のグラフ(Procの統計)で、sub_parts_voter.rbのinitialize()内で作られたProcが定期的に段を作るように増えて行っているのは、Gtk::TreeIterのメモリリーク対策で強制的にリストビューを破棄しているところで、そのProcが解放されずに残っているということかもしれない。

Actions

Copy link

#10

Updated by toshi_a 初音 almost 13 years ago

File out2.png out2.png added
File miraclepainter.png miraclepainter.png added

10時半以降のデータはmikutterの限界ｒｙ
Gdk::MiraclePainterが一切解放されていなかったので、 r632 で少し修正を加えた。
これで、コメント9で問題にしたcairo_subparts_voterのProcオブジェクトはMiraclePainterと共に解放されるようになった。
ただし、この版では、TLのリフレッシュ時にはMiraclePinterが解放されるようになったようだが、依然としてインスタンス数は添付のmiraclepainter.pngの通り増加していっている。タイムラインから溢れて削除する処理について、もう一度見直す。

Actions

Copy link

#11

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分程度かかっていること。サンプルを取る前に毎回明示的にガベージコレクタを呼んでいるので、この間どこかで参照が保持されていると考えられる。

Actions

Copy link

#12