bug#23369: 25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode

[Glenn Morris <rgm@gnu.org>]

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 ).