* Hard bug caused by window management code?
@ 2013-03-27 6:11 Dmitry Antipov
2013-03-27 7:07 ` Eli Zaretskii
2013-03-27 7:23 ` martin rudalics
0 siblings, 2 replies; 6+ messages in thread
From: Dmitry Antipov @ 2013-03-27 6:11 UTC (permalink / raw)
To: Emacs development discussions
[-- 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)))))
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Hard bug caused by window management code? 2013-03-27 6:11 Hard bug caused by window management code? Dmitry Antipov @ 2013-03-27 7:07 ` Eli Zaretskii 2013-03-27 7:23 ` martin rudalics 1 sibling, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2013-03-27 7:07 UTC (permalink / raw) To: Dmitry Antipov; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Hard bug caused by window management code? 2013-03-27 6:11 Hard bug caused by window management code? Dmitry Antipov 2013-03-27 7:07 ` Eli Zaretskii @ 2013-03-27 7:23 ` martin rudalics 2013-03-27 9:26 ` Dmitry Antipov 1 sibling, 1 reply; 6+ messages in thread From: martin rudalics @ 2013-03-27 7:23 UTC (permalink / raw) To: Dmitry Antipov; +Cc: Emacs development discussions > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Hard bug caused by window management code? 2013-03-27 7:23 ` martin rudalics @ 2013-03-27 9:26 ` Dmitry Antipov 2013-03-27 10:02 ` martin rudalics 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Antipov @ 2013-03-27 9:26 UTC (permalink / raw) To: Martin Rudalics; +Cc: Eli Zaretskii, Emacs development discussions 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Hard bug caused by window management code? 2013-03-27 9:26 ` Dmitry Antipov @ 2013-03-27 10:02 ` martin rudalics 2013-03-27 10:39 ` Dmitry Antipov 0 siblings, 1 reply; 6+ messages in thread From: martin rudalics @ 2013-03-27 10:02 UTC (permalink / raw) To: Dmitry Antipov; +Cc: Eli Zaretskii, Emacs development discussions >> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Hard bug caused by window management code? 2013-03-27 10:02 ` martin rudalics @ 2013-03-27 10:39 ` Dmitry Antipov 0 siblings, 0 replies; 6+ messages in thread From: Dmitry Antipov @ 2013-03-27 10:39 UTC (permalink / raw) To: martin rudalics; +Cc: Eli Zaretskii, Emacs development discussions 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-03-27 10:39 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-27 6:11 Hard bug caused by window management code? Dmitry Antipov 2013-03-27 7:07 ` Eli Zaretskii 2013-03-27 7:23 ` martin rudalics 2013-03-27 9:26 ` Dmitry Antipov 2013-03-27 10:02 ` martin rudalics 2013-03-27 10:39 ` Dmitry Antipov
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).