バグ #523
closedバグ #198: ダークマターの討伐
タイムラインのスクロールによるメモリ使用率の上昇
Description
タイムラインのスクロールバーをマウスでつかんで
何度も上下させているとメモリ使用率が急激に上昇する.
Messageオブジェクトは再生成されてないと思うので,
Gtk::VBoxか何かがキャッシュしてるんでしょうか…
Files
Updated by toshi_a 初音 about 12 years ago
症状的に、メモリリークの類だと思うので #198 と重複してると思います。そうなら、このチケットは却下ではなく #198 の子チケットにしようと思いますがどうでしょう (メモリを使う問題は多くの問題が絡んでいるので統合するのは望ましくない)。
先行チケットはメモリではなくオブジェクト数基準のデータしか上げてませんが、見ていただければわかる通り原因はタイムライン周りにあることは明白で、報告いただいたデータとこれまでの情報を総合すると、なかでもツイートがスクロールアウトしたときのオブジェクトの破棄には少なくとも問題がありそうです。
参考までに、Ruby, RubyGTK, GTKのバージョンを教えて下さい。
Updated by Takuma Nakajima about 12 years ago
子チケットの件,了解です.
ツイートがスクロールアウトしたときの動作ですが,この状態で数時間放置したあとに同じことをした結果,メモリ使用量は増加しませんでした.
(ずっとスクロール操作を続けた場合にどうなるかはまだ未検証です)
ガベージコレクション自体は動いていて,ガベージコレクトされた領域についてRuby(Gtk)が正しく把握していないか,
解放したメモリ領域が不連続もしくはGTK等に予約された状態になっていてOSに返されていないのではないか,とも考えました.憶測に過ぎませんが.
Ruby,RubyGTK,GTKのバージョンは以下の通りです.
----
ruby-1.9.3p125
ruby-gtk2-1.1.3
gtk+-3.2.4-r1
----
Updated by toshi_a 初音 about 12 years ago
メモリ使用量という観点から言えば、GCされたにもかかわらず一度拡大したスタックやヒープが縮小されてなくて、同様の症状が起こっているにもかかわらず、数字として顕在化していないという考え方もできます。一度 #198 の各コミットでどのような対策をしたか、どのような問題がわかったかをある程度書いているので見てみてください。放置しているのではなく、結果は出せてないけれど定期的に時間を割いて調査はしているが分からない、というのが現状です。
今は0.2のリリースに集中してるので見れませんが、予てからRubyGTKのバグもしくは使い方が誤っているのが原因と見ていて、根本的に解決するならmikutterではなくそれらのソースにコミットする必要があるかもしれないと考えていたし、もしそうなら(開発を続ける限り調査は続けるが)俺には修正できないと思っている、ということは伝えておきます。
いずれにせよ、 #198 を中心にして情報共有はしていきたいとは思ってます。
Updated by toshi_a 初音 about 12 years ago
- Target version deleted (
0.2) - Parent task set to #198
Updated by toshi_a 初音 almost 5 years ago
- Status changed from 新規 to 終了
- クラッシュする set to No