GNU bug report logs - #22975
25.0.92; CANNOT_DUMP build can't start in tty mode

Previous Next

Full log

Message #26 received at 22975 <at> debbugs.gnu.org (full text, mbox):

From: Kenneth Raeburn <raeburn <at> raeburn.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22975 <at> debbugs.gnu.org
Subject: Re: bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
Date: Fri, 11 Mar 2016 15:50:08 -0500

loadup.el has code testing (fboundp 'dump-emacs), it's not bound if CANNOT_DUMP is defined.

Ken


On Mar 11, 2016, at 14:47, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Ken Raeburn <raeburn <at> raeburn.org>
>> Date: Fri, 11 Mar 2016 14:18:55 -0500
>> Cc: 22975 <at> debbugs.gnu.org
>> 
>>>> On Mar 11, 2016, at 09:31, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> 
>>>> From: Ken Raeburn <raeburn <at> raeburn.org>
>>>> Date: Fri, 11 Mar 2016 06:17:45 -0500
>>>> Cc: 22975 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.