From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode Date: Fri, 11 Mar 2016 21:47:17 +0200 Message-ID: <83bn6kiypm.fsf@gnu.org> References: <4FF36A52-32D5-4AF3-A36E-621A57519C4F@raeburn.org> <83h9gen6yp.fsf@gnu.org> <83egbin5n9.fsf@gnu.org> <6D1E5FE8-518D-4433-8C11-7AF1C9D932ED@raeburn.org> <83oaaljdbb.fsf@gnu.org> <2AB9AB18-952B-4597-AB89-63D8F68D0434@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1457725704 30714 80.91.229.3 (11 Mar 2016 19:48:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2016 19:48:24 +0000 (UTC) Cc: 22975@debbugs.gnu.org To: Ken Raeburn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 11 20:48:13 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aeT2h-0003hY-DN for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Mar 2016 20:48:11 +0100 Original-Received: from localhost ([::1]:57387 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeT2g-0008MZ-Oa for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Mar 2016 14:48:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeT2c-0008MI-Q1 for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 14:48:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeT2Y-0002iB-DM for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 14:48:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48307) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeT2Y-0002i7-AD for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 14:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aeT2Y-0005fD-5d for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 14:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Mar 2016 19:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22975 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22975-submit@debbugs.gnu.org id=B22975.145772568121764 (code B ref 22975); Fri, 11 Mar 2016 19:48:02 +0000 Original-Received: (at 22975) by debbugs.gnu.org; 11 Mar 2016 19:48:01 +0000 Original-Received: from localhost ([127.0.0.1]:45434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aeT2X-0005ey-4I for submit@debbugs.gnu.org; Fri, 11 Mar 2016 14:48:01 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52315) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aeT2V-0005el-89 for 22975@debbugs.gnu.org; Fri, 11 Mar 2016 14:47:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeT2L-0002hK-Ib for 22975@debbugs.gnu.org; Fri, 11 Mar 2016 14:47:53 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeT2L-0002hG-Ej; Fri, 11 Mar 2016 14:47:49 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3974 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aeT2K-0005gz-P1; Fri, 11 Mar 2016 14:47:49 -0500 In-reply-to: <2AB9AB18-952B-4597-AB89-63D8F68D0434@raeburn.org> (message from Ken Raeburn on Fri, 11 Mar 2016 14:18:55 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114778 Archived-At: > From: Ken Raeburn > Date: Fri, 11 Mar 2016 14:18:55 -0500 > Cc: 22975@debbugs.gnu.org > > > On Mar 11, 2016, at 09:31, Eli Zaretskii wrote: > > > >> From: Ken Raeburn > >> 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.