Hard bug caused by window management code?

Hard bug caused by window management code?

[Dmitry Antipov]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

I'm trying to push some changes to window management code and now using a kind of
simple automated test stuff (attached), mostly to check whether the code doesn't
crash or trigger eassert. Results are totally unexpected - even with 24.3, running:

emacs -Q -l window-test.el -f window-test

causes 2.7G RSS and following OOM killer invocation for the Emacs process.

Can someone run this stuff and see what happens? (On MS-Windows or OSX, you
might want to look for test files somewhere else rather than in /etc).

Dmitry

[-- Attachment #2: window-test.el --]
[-- Type: text/plain, Size: 1188 bytes --]

;; Window random action test.

(defun random-entry (entries)
  (let ((size (length entries)))
    (if (= 1 size) (car entries)
      (nth (abs (% (random) (length entries))) entries))))

(defun window-test ()
  (interactive)
  (let ((conf (current-window-configuration))
	(file-list (directory-files "/etc" t "\\.conf$")))
    (while t
      (let ((action (abs (% (random) 11))))
	(cond ((zerop action)
	       (and (< 16 (window-height)) (split-window-vertically)))
	      ((= 1 action)
	       (and (< 16 (window-width)) (split-window-horizontally)))
	      ((= 2 action)
	       (and (< 1 (count-windows)) (delete-window)))
	      ((= 3 action)
	       (balance-windows))
	      ((= 4 action)
	       (delete-other-windows))
	      ((= 5 action)
	       (select-window (random-entry (window-list))))
	      ((= 6 action)
	       (let ((file (random-entry file-list)))
		 (and (file-readable-p file) (find-file file))))
	      ((= 7 action)
	       (kill-buffer))
	      ((= 8 action)
	       (setq conf (current-window-configuration)))
	      ((= 9 action)
	       (set-window-configuration conf))
	      ((= 10 action)
	       (mapcar 'kill-buffer (buffer-list))))
	(sit-for 0.2)))))

Re: Hard bug caused by window management code?

[Eli Zaretskii]

> Date: Wed, 27 Mar 2013 10:11:48 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> 
> I'm trying to push some changes to window management code and now using a kind of
> simple automated test stuff (attached), mostly to check whether the code doesn't
> crash or trigger eassert. Results are totally unexpected - even with 24.3, running:
> 
> emacs -Q -l window-test.el -f window-test
> 
> causes 2.7G RSS and following OOM killer invocation for the Emacs process.

Does it help to add

  (garbage-collect)

to the loop?

Re: Hard bug caused by window management code?

[martin rudalics]

 > Can someone run this stuff and see what happens? (On MS-Windows or OSX, you
 > might want to look for test files somewhere else rather than in /etc).

It seems to hang in `set-window-configuration'.  If you can confirm
that, it might help to first eliminate its loops that call
Qrecord_window_buffer and restore window parameters (these are not
vital).  If this doesn't reveal the culprit, we'd have to check whether
and where it hangs in the remaining loops (especially the main loop
following the call to delete_all_child_windows) by putting breakpoints
after these loops.  I never understood `set-window-configuration' well
and everything I attempted to fix there only increased my confusion.

martin

Re: Hard bug caused by window management code?

[Dmitry Antipov]

On 03/27/2013 11:23 AM, martin rudalics wrote:

> It seems to hang in `set-window-configuration'.

Now I'm seeing that enormously huge SIZE (3151760 !!!) passed from Lisp
to Fset_window_new_total causes an attempt to allocate appropriately huge
glyph matrix (window_resize_apply propagates this value from w->new_total
to w->total_lines, next it's used in window_box_height, and finally in
required_matrix_height, etc.). So:

1) Can you check lisp/window.el and find from where this SIZE comes?

2) Shouldn't we check whether SIZE in Fset_window_new_total and
    Fset_window_new_normal isn't too large, for example, not larger
    than the appropriate dimension of the frame contains WINDOW?

Dmitry

Re: Hard bug caused by window management code?

[martin rudalics]

 >> It seems to hang in `set-window-configuration'.

Could you confirm that?

 > Now I'm seeing that enormously huge SIZE (3151760 !!!) passed from Lisp
 > to Fset_window_new_total

This could come from the following line in delete_all_child_windows

   wset_total_lines (w, w->buffer);

which is later on used as

	  if (BUFFERP (w->total_lines))
	    wset_buffer (w, w->total_lines);

in `set-window-configuration' and escaped my understanding ever since.
Note the "Kludge Alert" there.

 > causes an attempt to allocate appropriately huge
 > glyph matrix (window_resize_apply propagates this value from w->new_total
 > to w->total_lines, next it's used in window_box_height, and finally in
 > required_matrix_height, etc.). So:
 >
 > 1) Can you check lisp/window.el and find from where this SIZE comes?

See above.  I do not have any other clues.

 > 2) Shouldn't we check whether SIZE in Fset_window_new_total and

This would be _usually_ caught by window_resize_check.  But note that
`set-window-configuration' is special in this regard.

 >    Fset_window_new_normal isn't too large,

This is a float and should by always <= 1.  Any wrong value here should
never have grave implications like the one you observed.

 > for example, not larger
 >    than the appropriate dimension of the frame contains WINDOW?

martin

Re: Hard bug caused by window management code?

[Dmitry Antipov]

On 03/27/2013 02:02 PM, martin rudalics wrote:

>  >> It seems to hang in `set-window-configuration'.
>
> Could you confirm that?

There might be more than one reason. After installing simple check in src/window.c:

@@ -3488,6 +3488,10 @@
    struct window *w = decode_valid_window (window);

    CHECK_NUMBER (size);
+
+  if (XINT (size) > 100000)
+    emacs_abort ();
+
    if (NILP (add))
      wset_new_total (w, size);
    else

I'm seeing:

(gdb) bt
#0  emacs_abort () at sysdep.c:2152
#1  0x0000000000482eb1 in Fset_window_new_total (window=18673781, size=12607040, add=12519810) at window.c:3493
#2  0x00000000005add37 in Ffuncall (nargs=4, args=0x7fffffffc348) at eval.c:2785
#3  0x00000000005f47d9 in exec_byte_code (bytestr=9362689, vector=9362725, maxdepth=36, args_template=12519762, nargs=0, args=0x0)
     at bytecode.c:900
#4  0x00000000005ae6e1 in funcall_lambda (fun=9362541, nargs=5, arg_vector=0x7fffffffc850) at eval.c:3010
#5  0x00000000005aded9 in Ffuncall (nargs=6, args=0x7fffffffc848) at eval.c:2827
#6  0x00000000005f47d9 in exec_byte_code (bytestr=9363137, vector=9363173, maxdepth=40, args_template=12519762, nargs=0, args=0x0)
     at bytecode.c:900
#7  0x00000000005ae6e1 in funcall_lambda (fun=9363085, nargs=2, arg_vector=0x7fffffffcd78) at eval.c:3010
#8  0x00000000005aded9 in Ffuncall (nargs=3, args=0x7fffffffcd70) at eval.c:2827
#9  0x00000000005ad6cf in call2 (fn=12733826, arg1=18673781, arg2=12607040) at eval.c:2587
#10 0x0000000000484892 in shrink_mini_window (w=0x11fc350) at window.c:4235
#11 0x000000000043ecb7 in resize_mini_window (w=0x11fc350, exact_p=1) at xdisp.c:10441
#12 0x000000000043e6b7 in resize_mini_window_1 (a1=18858832, exactly=12519810, a3=0, a4=0) at xdisp.c:10325
#13 0x000000000043de2c in with_echo_area_buffer (w=0x11fc350, which=0, fn=0x43e678 <resize_mini_window_1>, a1=18858832, a2=12519810,
     a3=0, a4=0) at xdisp.c:10062
#14 0x000000000043e64a in resize_echo_area_exactly () at xdisp.c:10302
#15 0x0000000000513cc4 in command_loop_1 () at keyboard.c:1374
#16 0x00000000005aaadd in internal_condition_case (bfun=0x513bd8 <command_loop_1>, handlers=12571394, hfun=0x5134c9 <cmd_error>)
     at eval.c:1289
#17 0x00000000005138f4 in command_loop_2 (ignore=12519762) at keyboard.c:1168
#18 0x00000000005aa4ba in internal_catch (tag=12567234, func=0x5138ce <command_loop_2>, arg=12519762) at eval.c:1060
#19 0x00000000005138a2 in command_loop () at keyboard.c:1147
#20 0x0000000000513019 in recursive_edit_1 () at keyboard.c:779
#21 0x00000000005131bc in Frecursive_edit () at keyboard.c:843
#22 0x000000000051106d in main (argc=6, argv=0x7fffffffe348) at emacs.c:1528

Lisp Backtrace:
"set-window-new-total" (0xffffc350)
"window--resize-this-window" (0xffffc850)
"window--resize-root-window-vertically" (0xffffcd78)

Dmitry