bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode

[Eli Zaretskii]

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Fri, 11 Mar 2016 14:18:55 -0500
> Cc: 22975@debbugs.gnu.org
> 
> > On Mar 11, 2016, at 09:31, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Ken Raeburn <raeburn@raeburn.org>
> >> Date: Fri, 11 Mar 2016 06:17:45 -0500
> >> Cc: 22975@debbugs.gnu.org
> >> 
> >> It appears that Emacs tries to display the “Using load-path …” message, 
> >> calls echo_area_display, display_echo_area, with_echo_area_buffer, 
> >> display_echo_area_1, resize_mini_window, and grow_mini_window, which then 
> >> uses
> >>  call3 (Qwindow_resize_root_window_vertically, …)
> >> but since we haven’t loaded window.el yet, there’s no function definition 
> >> and we raise a signal, quitting out of loadup and trying to display a 
> >> message.
> > 
> > I'm not sure I follow: message calls message3_nolog, which should have
> > done this:
> > 
> >  void
> >  message3_nolog (Lisp_Object m)
> >  {
> >    struct frame *sf = SELECTED_FRAME ();
> > 
> >    if (FRAME_INITIAL_P (sf))
> >      message_to_stderr (m);
> > 
> > Is FRAME_INITIAL_P not doing it job in this case?
> 
> With “-nw”, sf->output_method is output_termcap. It’s cleared the window and 
> drawn a line of dashes near the bottom, and messages are displayed on the 
> bottom line (when it’s not crashing).
> 
> Without “-nw”, sf->output_method is output_initial and messages are printed 
> to stderr line by line until the X frame opens.
> 
> > And just so I'm on the right page here: the "Loading foo..." messages
> > that loadup.el displays are shown where in this case? written to
> > stderr or displayed in the echo area?
> 
> In the echo area.
> 
> > 
> >> As to why normal temacs doesn’t show the problem: The load path displayed 
> >> for a normal temacs contains one directory, but for a CANNOT_DUMP emacs it 
> >> contains several; in my tests, resize_mini_window computed the height 
> >> needed as one line for the former and six lines for the latter, so only in 
> >> the latter case did grow_mini_window need to get called.
> > 
> > I think temacs should write these messages to stderr, so the whole
> > resize_mini_window rigmarole shouldn't get called at all.  What am I
> > missing?
> 
> In init_display we call init_tty and then update the frame’s output_method. 
> Under X11, the X frame creation happens much later.

OK, I see.  So now it's crystal clear that bidi-display-reordering
should be bound to nil until loadup finishes, otherwise we are
playing with fire.

Is there a way to know that the build CANNOT_DUMP from Lisp?

> > Error loop that displays what messages?
> 
> *Tries* to display… From the stack trace, it looks like it’s throwing an 
> error that window—-resize-root-window-vertically isn’t defined, then back at 
> the top level we notice we’re displaying a message, so we call 
> resize_echo_area_exactly, which decides to resize, which tries to call 
> window—resize-root-window-vertically, etc.

Right, all is clear now.

Thanks.