GNU bug report logs -
#23369
25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode
Previous Next
Reported by: Fredrik Fornwall <fredrik <at> fornwall.net>
Date: Mon, 25 Apr 2016 07:19:03 UTC
Severity: normal
Tags: confirmed
Found in version 25.0.93
Fixed in version 25.0.94
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #37 received at 23369 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> I can't get one. I just get "NSTATICS too small" (even if I make it huge).
>
> If you run that command under GDB, with a breakpoint on the code which
> issues this message, don't you get the backtrace?
It's not a relevant message.
Anyway, I managed to get a useful backtrace, which revealed the real
problem, and a trivial fix:
Lisp Backtrace:
"frames-on-display-list" (0xffff17e0)
"let" (0xffff19d0)
"mapcar" (0xffff1d50)
"apply" (0xffff1ed0)
"cons" (0xffff1ff0)
"internal--before-save-selected-window" (0xffff2160)
"let" (0xffff2450)
"save-selected-window" (0xffff2570)
"walk-windows" (0xffff26e0)
"let" (0xffff2a20)
"window--process-window-list" (0xffff2b90)
"let" (0xffff2e80)
"dolist" (0xffff2fa0)
"window--adjust-process-windows" (0xffff31e0)
"load" (0xffff3800)
*** a/lisp/window.el
--- b/lisp/window.el
***************
*** 8520,8525 ****
--- 8520,8526 ----
displaying that processes's buffer."
(let ((processes (process-list))
(process-windows nil))
+ (when processes
(walk-windows
(lambda (window)
(let ((buffer (window-buffer window))
***************
*** 8538,8544 ****
nil)
(setf iter (cdr iter)))))))
1 t)
! process-windows))
(defun window--adjust-process-windows ()
"Update process window sizes to match the current window configuration."
--- 8539,8545 ----
nil)
(setf iter (cdr iter)))))))
1 t)
! process-windows)))
(defun window--adjust-process-windows ()
"Update process window sizes to match the current window configuration."
>> >> Also, it seems like if CANNOT_DUMP builds encounter an error loading
>> >> loadup.el, they go on to run the command-loop with only a partially
>> >> loaded loadup, which leads to confusing error messages that have nothing
>> >> to do with the real problem. Can they be made to abort instead?
>> >
>> > How will aborting help diagnosing the problems? IME, it tends to hide
>> > evidence, not make it more clear.
>>
>> In that Emacs might stop near the actual error (eg "loading foo..."),
>> rather than going on to fail with some totally unrelated error (eg
>> "Symbol's function definition is void: internal-echo-keystrokes-prefix"
>> as in this case).
>
> But the error message is actually quite informative; at the very
> least, it tells where the problem happened, and frequently also names
> the guilty function or variable.
I feel like we are miscommunicating.
Neither of the errors mentioned in the original report (NSTATICS,
internal-echo-keystrokes-prefix) have anything to do with the real
problem. They are just noise caused by an Emacs with half its loadup
missing falling through to the command-loop and inevitably failing
miserably. This is not informative. If there is an error loading loadup,
it should print it and abort. (I see I am repeating
http://debbugs.gnu.org/22975#38 ).
This bug report was last modified 9 years and 84 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.