From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenneth Raeburn Newsgroups: gmane.emacs.bugs Subject: bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode Date: Fri, 11 Mar 2016 15:50:08 -0500 Message-ID: <49B8443F-2416-44A5-BE6B-A25D690E8CF5@raeburn.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> <83bn6kiypm.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1457729484 25624 80.91.229.3 (11 Mar 2016 20:51:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2016 20:51:24 +0000 (UTC) Cc: 22975@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 11 21:51:12 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 1aeU1f-0008Uo-CG for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Mar 2016 21:51:11 +0100 Original-Received: from localhost ([::1]:57622 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeU1e-0005Ab-Ud for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Mar 2016 15:51:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeU1b-0005AW-8Z for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 15:51:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeU1W-0003K3-Ki for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 15:51:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeU1W-0003Jz-Gx for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 15:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aeU1W-0007Du-BP for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 15:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Kenneth Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Mar 2016 20:51: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.145772941727712 (code B ref 22975); Fri, 11 Mar 2016 20:51:02 +0000 Original-Received: (at 22975) by debbugs.gnu.org; 11 Mar 2016 20:50:17 +0000 Original-Received: from localhost ([127.0.0.1]:45480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aeU0n-0007Cu-4R for submit@debbugs.gnu.org; Fri, 11 Mar 2016 15:50:17 -0500 Original-Received: from mail-qg0-f45.google.com ([209.85.192.45]:36667) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aeU0l-0007Ci-VA for 22975@debbugs.gnu.org; Fri, 11 Mar 2016 15:50:16 -0500 Original-Received: by mail-qg0-f45.google.com with SMTP id u110so108507735qge.3 for <22975@debbugs.gnu.org>; Fri, 11 Mar 2016 12:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l+GJ5RHNtTiym0Hpzs0lEoaCfPTkOfAzqJZm/cGYuu0=; b=viFKC1gCl2n8I+FQR7yUmQvPd7s77YlYAxXoLWwHzl1CUUr0gDro1zBe18oEu2WCFk pCUq8wlC8o5e9OTqoftnPU38K7+qasaLJ2vxdxgHGQxmFoe2R8x2kX15YX1DY3sNcEyf ThdFpdWv8VyrscHOLMlkTqpYLPlW0dhF4mg6r0txBzkDYMtaHv9BWhXr030nUq4+qE91 TpGW+tsO/b0us7JYAwARmIGH8XeZkMj1EMpJsFEsMq6JPenPo7vjslpmpkW0X4IgJVCF KbrrM0bO5Qw5/tCn1PwOpMEr4iRERO4cUSuWxVdDCtnFQH2V3owRZ55pcP/UTY3D64KY 9O5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l+GJ5RHNtTiym0Hpzs0lEoaCfPTkOfAzqJZm/cGYuu0=; b=Z7VVqLdo+CVOgufK+UKDLCVUGw6+551lz4vXMOdVOSQvHHptldqjbTF1GdXdYxR0fm k1e9/D+N8uv5d9cK6Tjw2Z77+eDrTuHHmK9iuyiOIFHaTNNFHKvxPn38dNxzLjRtNeKr 6J0GJh6LhWlz175SGokpp0wvUnnr5Wapa23QJZFUnIXFIyiSwTVhCrwEHaSEjiWmHkdk YXffeMP8+Rexc94/B6ia9iqLTakfuwmldecC5Ke0w6kyhAuNzceF99sY2ldLPOn3Ne/h 5bt+af6DoVbFr/WTwY427HDrYo4E4s5wJG/KAnlcily7Hk/fTHvOqmwteleDdmLcMnn7 1A8g== X-Gm-Message-State: AD7BkJJ8X1Ado/0yY+IAKBWKfBVQBaxqdYnwLqYFaFxA5wuWXpBP9o8vknH34k8Cj03Ycg== X-Received: by 10.140.201.209 with SMTP id w200mr15362039qha.57.1457729410346; Fri, 11 Mar 2016 12:50:10 -0800 (PST) Original-Received: from [10.1.12.69] (vpn.permabit.com. [66.202.84.2]) by smtp.gmail.com with ESMTPSA id i14sm4771522qkh.6.2016.03.11.12.50.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2016 12:50:08 -0800 (PST) X-Mailer: iPhone Mail (13D15) In-Reply-To: <83bn6kiypm.fsf@gnu.org> 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:114784 Archived-At: loadup.el has code testing (fboundp 'dump-emacs), it's not bound if CANNOT_D= UMP is defined. Ken On Mar 11, 2016, at 14:47, Eli Zaretskii wrote: >> From: Ken Raeburn >> Date: Fri, 11 Mar 2016 14:18:55 -0500 >> Cc: 22975@debbugs.gnu.org >>=20 >>>> On Mar 11, 2016, at 09:31, Eli Zaretskii wrote: >>>>=20 >>>> From: Ken Raeburn >>>> Date: Fri, 11 Mar 2016 06:17:45 -0500 >>>> Cc: 22975@debbugs.gnu.org >>>>=20 >>>> It appears that Emacs tries to display the =E2=80=9CUsing load-path =E2= =80=A6=E2=80=9D message, calls echo_area_display, display_echo_area, with_ec= ho_area_buffer, display_echo_area_1, resize_mini_window, and grow_mini_windo= w, which then uses >>>> call3 (Qwindow_resize_root_window_vertically, =E2=80=A6) >>>> but since we haven=E2=80=99t loaded window.el yet, there=E2=80=99s no f= unction definition and we raise a signal, quitting out of loadup and trying t= o display a message. >>>=20 >>> I'm not sure I follow: message calls message3_nolog, which should have >>> done this: >>>=20 >>> void >>> message3_nolog (Lisp_Object m) >>> { >>> struct frame *sf =3D SELECTED_FRAME (); >>>=20 >>> if (FRAME_INITIAL_P (sf)) >>> message_to_stderr (m); >>>=20 >>> Is FRAME_INITIAL_P not doing it job in this case? >>=20 >> With =E2=80=9C-nw=E2=80=9D, sf->output_method is output_termcap. It=E2=80= =99s cleared the window and drawn a line of dashes near the bottom, and mess= ages are displayed on the bottom line (when it=E2=80=99s not crashing). >>=20 >> Without =E2=80=9C-nw=E2=80=9D, sf->output_method is output_initial and me= ssages are printed to stderr line by line until the X frame opens. >>=20 >>> 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? >>=20 >> In the echo area. >>=20 >>>=20 >>>> As to why normal temacs doesn=E2=80=99t 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 hei= ght needed as one line for the former and six lines for the latter, so only i= n the latter case did grow_mini_window need to get called. >>>=20 >>> 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? >>=20 >> In init_display we call init_tty and then update the frame=E2=80=99s outp= ut_method. Under X11, the X frame creation happens much later. >=20 > 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. >=20 > Is there a way to know that the build CANNOT_DUMP from Lisp? >=20 >>> Error loop that displays what messages? >>=20 >> *Tries* to display=E2=80=A6 =46rom the stack trace, it looks like it=E2=80= =99s throwing an error that window=E2=80=94-resize-root-window-vertically is= n=E2=80=99t defined, then back at the top level we notice we=E2=80=99re disp= laying a message, so we call resize_echo_area_exactly, which decides to resi= ze, which tries to call window=E2=80=94resize-root-window-vertically, etc. >=20 > Right, all is clear now. >=20 > Thanks.