bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ken Raeburn
Subject: bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
Date: Fri, 11 Mar 2016 14:18:55 -0500

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

> 
>> If I mess around with installation prefix length, window size, and font 
>> size, I can get the CANNOT_DUMP emacs to start properly (but with unreadably 
>> tiny characters); and if I make my terminal window quite narrow, I can get a 
>> normal temacs to get into some kind of error loop (not the same failure mode 
>> but probably a similar root cause). So it’s not just the CANNOT_DUMP setting 
>> that’s causing the problem.
> 
> 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.

Ken




reply via email to

[Prev in Thread] Current Thread [Next in Thread]