日本語ファイルをスクロールするとメモリリークを起こしてしまう

うまく再現させることができないのですが、以下のパッチで挙動が変わったりしますでしょうか。

Index: mw32fns.c
===================================================================
--- mw32fns.c   (revision 4166)
+++ mw32fns.c   (working copy)
@@ -1909,8 +1909,7 @@
        f->output_data.mw32->hdc = (HDC) wParam;
        f->output_data.mw32->hdc_nestlevel = 1;

-       if (!GetUpdateRect (FRAME_MW32_WINDOW (f), &rect, FALSE))
-         GetClientRect (FRAME_MW32_WINDOW (f), &rect);
+       GetClientRect (FRAME_MW32_WINDOW (f), &rect);
        mw32_clear_native_frame_area (f, rect.left, rect.top,
                                      rect.right, rect.bottom);

メモリリークではなくて、無駄に大きなメモリを確保しているのだと思います。 特に desired_matrix/current_matrix に対して。

cols_scale_factor がインクリメントされることがあって、required_matrix_width()@dispnew.c が大きな幅を返すことが一因かな?

いずれにしても、本家の方で描画系に色々と手が入っているところですので、しばらく様子を見ます。

yamazakiさんの変更では、変わりませんでした。18KBのfileで、スクロールを繰り返すことで最高305MBまでメモリを占有することを確認しました。 フレームサイズが大きいほど、無駄に確保するメモリが大きいようです。

r4166は、使用していると日に何度か再起動しなければいけませんし、miyoshiさん曰くしばらくこのままということでr4148を当面使用したいと思います。

時間が少しあったのでもう少し調べたところ、r4158までは大丈夫であることがわかりました。r4156であったというのは訂正しておきます。

本家の不具合と言うことで、r4161のsyncで問題の件が混入したのでしょうね。

ちょっと時間が取れたので調べてみました。 これは Emacs のバグです。NTEmacs でも再現しました。おそらく他のプラットフォームでも再現するはず。

原因は以下の通りです。

• append_glyph() -> IT_EXPAND_MATRIX_WIDTH() で it->w->ncols_scale_factor が不必要にインクリメントされ続ける
• required_matrix_width()が返す値も増え続ける
• adjust_glyph_matrix()にてグリフ用のメモリが延々と拡張される

もう少し調べてみます。

手元では下記のようなひどい状況が再現できません。このファイルを提供してもらえませんか?

yamazakiさんの変更では、変わりませんでした。18KBのfileで、
スクロールを繰り返すことで最高305MBまでメモリを占有することを確認しました。

それから、次のパッチが効果があるか試してください。 無駄なメモリ確保の一因がこの部分にありそうです。

--- ./xdisp.c.orig	2006-10-08 16:34:37.308646400 +0900
+++ ./xdisp.c	2006-10-08 16:34:56.476208000 +0900
@@ -1311,6 +1311,7 @@
 
   SET_TEXT_POS_FROM_MARKER (top, w->start);
 
+#if 0
   /* Compute exact mode line heights.  */
   if (WINDOW_WANTS_MODELINE_P (w))
     current_mode_line_height
@@ -1321,6 +1322,7 @@
     current_header_line_height
       = display_mode_line (w, HEADER_LINE_FACE_ID,
 			       current_buffer->header_line_format);
+#endif
 
   start_display (&it, w, top);
   move_it_to (&it, charpos, -1, it.last_visible_y-1, -1,

r4166にmiyoshiさんの修正をあてることで、無駄にメモリを確保することは無くなったようです(同じファイルで大体254KB以上は増えなくなりました)。

再現できない人もいるようですので環境も書いておきます(遅すぎてすみません)。 Windows2000SP4 Athlon64 3200+ メモリ1GB　画面サイズ1600x1200です。画面サイズが大きいほど大きなメモリを確保していました。確認した日本語ファイルはふつうのSJISとフォント設定用のiso-2022-7bit-dos のものでした。

確認ありがとうございます。

何か対策を考えますのでreopenします。

mule-jaに報告しました。

CVS HEAD の Emacs 22 に、Emacs が消費するメモリが際限なく増加する
という問題があります。

元々は Meadow で報告された問題なのですが、Windows の Emacs
(NTEmacs)でも再現することを確認しました。おそらく、他のプラット
フォームでも再現すると思います。

少し調べてみたのですが、私の手に負えそうにはないので、こちらに報告
します。


再現方法：
o 日本語を多数含むファイルを C-x C-f で読み込む
o C-n で下方向にカーソルを移動する
o スクロールが生じるタイミングでメモリ消費量が増える


分かっていること：

以下の修正で問題が発生するようになった模様。
> 2006-09-06  Kim F. Storm  <storm@cua.dk>
> 
> 	* xdisp.c (pos_visible_p): Remove exact_mode_line_heights_p arg;
> 	so calculate heights even when pos-visible-in-window-p is called
> 	with partially = t.  Don't overshoot last_visible_y in move_it_to.
> 	Return row height and row number in new rowh and vpos args.


まず、以下のコールシーケンスで it->w->ncols_scale_factor が、何回
もインクリメントされます。

In xdisp.c:
pos_visible_p()
->display_mode_line()
->display_mode_element() ;; case MODE_LINE_DISPLAY:
->display_string()
->PRODUCE_GLYPHS()
->x_produce_glyphs() ;; RIF
->append_glyph() ;; it->glyph_row->used[area] がインクリメント
->IT_EXPAND_MATRIX_WIDTH() ;; その結果 it->w->ncols_scale_factor
                           ;; がインクリメント

そのため、required_matrix_width()@dispnew.c が大きな値を返します。

その結果、adjust_glyph_matrix()@dispnew.c にて、グリフ用のメモリが
不足していると判定して、xrealloc() でよってメモリを拡張し続けます。

発生条件としては、さらに、

表示がキー入力に間に合わなくなった場合

のようです。

pos_visible_p では実際に表示処理を行うのではないので、pos_visible_p から呼ばれた場合は append_glyph を呼ばないようにすればメモリの問題は解決できると思います。処理自体が重いのは「FALSE を返せる場合に display_mode_line を呼ばないで済ます」などの改善余地はあるように感じます。

皆さんお疲れ様です。

＞発生条件としては、さらに、 
＞表示がキー入力に間に合わなくなった場合 

そういえば私も、kbdaccと言うキー入力加速ツールを常駐させていました。
以上、よろしくお願いいたします。

本家で修正してもらいました。

この修正をr4174で取り込みましたので、お試しください。

対応ありがとうございました。 正常に動作していることが確認できました。