From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: bug#17622: 24.4.50; bootstrap failure Date: Thu, 29 May 2014 15:54:23 +0200 Message-ID: References: <53872A40.3020000@cornell.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf303bfebe6ab58204fa8a4583 X-Trace: ger.gmane.org 1401371786 6671 80.91.229.3 (29 May 2014 13:56:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2014 13:56:26 +0000 (UTC) Cc: 17622 <17622@debbugs.gnu.org>, Katsumi Yamaoka To: Ken Brown Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 29 15:56:20 2014 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 1Wq0oe-00044K-9q for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 May 2014 15:56:20 +0200 Original-Received: from localhost ([::1]:48300 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wq0od-0006ba-Um for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 May 2014 09:56:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wq0oU-0006b3-PT for bug-gnu-emacs@gnu.org; Thu, 29 May 2014 09:56:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wq0oO-0006vf-Jo for bug-gnu-emacs@gnu.org; Thu, 29 May 2014 09:56:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wq0oO-0006vU-G7 for bug-gnu-emacs@gnu.org; Thu, 29 May 2014 09:56:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Wq0oN-0007Vi-Cg for bug-gnu-emacs@gnu.org; Thu, 29 May 2014 09:56:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Fabrice Popineau Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 May 2014 13:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17622 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17622-submit@debbugs.gnu.org id=B17622.140137170228394 (code B ref 17622); Thu, 29 May 2014 13:56:02 +0000 Original-Received: (at 17622) by debbugs.gnu.org; 29 May 2014 13:55:02 +0000 Original-Received: from localhost ([127.0.0.1]:35385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wq0nJ-0007NN-2k for submit@debbugs.gnu.org; Thu, 29 May 2014 09:55:01 -0400 Original-Received: from mail-ie0-f176.google.com ([209.85.223.176]:54927) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wq0nB-0007Mw-PI for 17622@debbugs.gnu.org; Thu, 29 May 2014 09:54:54 -0400 Original-Received: by mail-ie0-f176.google.com with SMTP id rl12so293549iec.7 for <17622@debbugs.gnu.org>; Thu, 29 May 2014 06:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VAQYIE3L+/t3hIAvmBXTzt9foh5rB/GZ+GTf++EgMbQ=; b=WvM+54i83kOfy1t70KeOBaVynvyp4hvOXsAo5ZkpqE3Zu2oZqSuWESVziuUERADhSE axCvNHPFM2tRXq7+wIcqXG0fpKIPT4EqcKccBfqZPpLZRoyLFundO0IoUiUgNPA7YzRm b6ychNpE7HMR9BKxp2FH4d2v21bdLKBAmEHQT0kraxpFhltJsIrVTXYa3UxW4BwN5NpZ Mdy16hAWWDPxQ1KdxLjnyDbGc0n2HkjSSNd8as1bBFY24cCDN3IFzi79H7iUx/B0yy1T EVsqHYNc7wyfk3RXl675lIGlBXxuAjc9Tb8TVDVEihPJ+EuW7VIxIRvTOm/fJDO2UTtO Ro2w== X-Received: by 10.42.185.72 with SMTP id cn8mr7260062icb.63.1401371683892; Thu, 29 May 2014 06:54:43 -0700 (PDT) Original-Received: by 10.64.10.202 with HTTP; Thu, 29 May 2014 06:54:23 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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:89674 Archived-At: --20cf303bfebe6ab58204fa8a4583 Content-Type: text/plain; charset=UTF-8 This should fix the problem: --- ../trunk/src/buffer.c 2014-05-29 15:51:11.632003900 +0200 +++ src/buffer.c 2014-05-29 15:50:54.192190300 +0200 @@ -4703,11 +4703,6 @@ static int mmap_fd; -/* Temporary storage for mmap_set_vars, see there. */ - -static struct mmap_region *mmap_regions_1; -static int mmap_fd_1; - /* Page size on this system. */ static int mmap_page_size; @@ -5282,6 +5277,9 @@ { struct buffer *b; + mmap_regions = NULL; + mmap_fd = -1; + /* We cannot dump buffers with meaningful addresses that can be used by the dumped Emacs. We map new memory for them here. */ FOR_EACH_BUFFER (b) by initializing explicitly variables that need it. We can also remove unsused variables. Waiting for confirmation (or failure!). Fabrice 2014-05-29 14:55 GMT+02:00 Fabrice Popineau : > Probably ok because I ran like this for a while, > but I wonder if it couldn't be handled at the beginning of > bufffer.c:init_buffer() instead. > What I suggest is do what mmap_set_vars(0) does > inside init_buffer() rather than reinstate mmap_set_vars(). > Not a great advantage, except to clarify that these pointers should be > initialized > when starting the dumped emacs instead of relying on what is dumped. > > Fabrice > > > > > > > 2014-05-29 14:38 GMT+02:00 Ken Brown : > > On 5/29/2014 12:56 AM, Katsumi Yamaoka wrote: >> >>> I verified simply reverting r117168 builds Emacs successfully on >>> Cygwin. >>> >> >> The removal of mmap_set_vars is what caused the problem. The following >> patch fixes restores mmap_set_vars and fixes the problem. Eli and Fabrice, >> is the w32 build still OK with this patch? >> >> === modified file 'src/buffer.c' >> --- src/buffer.c 2014-05-27 17:31:17 +0000 >> +++ src/buffer.c 2014-05-29 12:23:53 +0000 >> @@ -4855,6 +4855,38 @@ >> } >> >> >> +/* Set or reset variables holding references to mapped regions. >> + If not RESTORE_P, set all variables to null. If RESTORE_P, set all >> + variables to the start of the user-areas of mapped regions. >> + >> + This function is called from Fdump_emacs to ensure that the dumped >> + Emacs doesn't contain references to memory that won't be mapped >> + when Emacs starts. */ >> + >> +void >> +mmap_set_vars (bool restore_p) >> +{ >> + struct mmap_region *r; >> + >> + if (restore_p) >> + { >> + mmap_regions = mmap_regions_1; >> + mmap_fd = mmap_fd_1; >> + for (r = mmap_regions; r; r = r->next) >> + *r->var = MMAP_USER_AREA (r); >> + } >> + else >> + { >> + for (r = mmap_regions; r; r = r->next) >> + *r->var = NULL; >> + mmap_regions_1 = mmap_regions; >> + mmap_regions = NULL; >> + mmap_fd_1 = mmap_fd; >> + mmap_fd = -1; >> + } >> +} >> + >> + >> /* Allocate a block of storage large enough to hold NBYTES bytes of >> data. A pointer to the data is returned in *VAR. VAR is thus the >> address of some variable which will use the data area. >> >> === modified file 'src/emacs.c' >> --- src/emacs.c 2014-05-27 17:31:17 +0000 >> +++ src/emacs.c 2014-05-29 12:28:19 +0000 >> @@ -2155,8 +2155,13 @@ >> malloc_state_ptr = malloc_get_state (); >> #endif >> >> +#if defined USE_MMAP_FOR_BUFFERS && !defined WINDOWSNT >> + mmap_set_vars (0); >> +#endif >> unexec (SSDATA (filename), !NILP (symfile) ? SSDATA (symfile) : 0); >> - >> +#if defined USE_MMAP_FOR_BUFFERS && !defined WINDOWSNT >> + mmap_set_vars (1); >> +#endif >> #ifdef DOUG_LEA_MALLOC >> free (malloc_state_ptr); >> #endif >> >> >> Ken >> > > --20cf303bfebe6ab58204fa8a4583 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This should fix the problem:

--- .= ./trunk/src/buffer.c =C2=A0 =C2=A0 =C2=A0 2014-05-29 15:51:11.632003900 +02= 00
+++ src/buffer.c =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-29 15:50:5= 4.192190300 +0200
@@ -4703,11 +4703,6 @@

=C2=A0static int mmap_fd;

-/* = Temporary storage for mmap_set_vars, see there. =C2=A0*/
-
<= div>-static struct mmap_region *mmap_regions_1;
-static int mmap_= fd_1;
-
=C2=A0/* Page size on this system. =C2=A0*/

=
=C2=A0static int mmap_page_size;
@@ -5282,6 +5277,9 @@=
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0struct buffer *b;

+ =C2=A0 =C2=A0mmap_regions =3D NULL;
+ =C2=A0 =C2=A0mmap_fd =3D -1;
+
=C2=A0 =C2=A0 =C2= =A0/* We cannot dump buffers with meaningful addresses that can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used by the dumped Emacs. =C2=A0We map new me= mory for them here. =C2=A0*/
=C2=A0 =C2=A0 =C2=A0FOR_EACH_BUFFER = (b)

by initializing explicitly variables that need it= . We can also remove unsused variables.
Waiting for confirmation = (or failure!).

Fabrice


2014-05-29 14:55 GMT+02:00 Fabrice Popin= eau <fabrice.popineau@gmail.com>:
Probably ok because I ran like this for a while,=C2=A0but I wonder if it couldn't be handled at the beginning of bufffer.c:i= nit_buffer() instead.
What I suggest is do what mmap_set_vars(0) = does=C2=A0
inside init_buffer() rather than reinstate mmap_set_vars().
= Not a great advantage, except to clarify that these pointers should be init= ialized
when starting the dumped emacs instead of relying on what= is dumped.

Fabrice




<= /div>


2014-05-29 14:38 GMT+02:00 Ken Brown <kbrown@cornell.edu>:

On 5/29/2014 12:56 AM, Katsumi Yamaoka wrote= :
I verified simply reverting r117168 builds Emacs successfully on
Cygwin.

The removal of mmap_set_vars is what caused the problem. =C2=A0The followin= g patch fixes restores mmap_set_vars and fixes the problem. =C2=A0Eli and F= abrice, is the w32 build still OK with this patch?

=3D=3D=3D modified file 'src/buffer.c'
--- src/buffer.c =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-27 17:31:17 +0000
+++ src/buffer.c =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-29 12:23:53 +0000
@@ -4855,6 +4855,38 @@
=C2=A0}


+/* Set or reset variables holding references to mapped regions.
+ =C2=A0 If not RESTORE_P, set all variables to null. =C2=A0If RESTORE_P, s= et all
+ =C2=A0 variables to the start of the user-areas of mapped regions.
+
+ =C2=A0 This function is called from Fdump_emacs to ensure that the dumped=
+ =C2=A0 Emacs doesn't contain references to memory that won't be m= apped
+ =C2=A0 when Emacs starts. =C2=A0*/
+
+void
+mmap_set_vars (bool restore_p)
+{
+ =C2=A0struct mmap_region *r;
+
+ =C2=A0if (restore_p)
+ =C2=A0 =C2=A0{
+ =C2=A0 =C2=A0 =C2=A0mmap_regions =3D mmap_regions_1;
+ =C2=A0 =C2=A0 =C2=A0mmap_fd =3D mmap_fd_1;
+ =C2=A0 =C2=A0 =C2=A0for (r =3D mmap_regions; r; r =3D r->next)
+ =C2=A0 =C2=A0 =C2=A0 *r->var =3D MMAP_USER_AREA (r);
+ =C2=A0 =C2=A0}
+ =C2=A0else
+ =C2=A0 =C2=A0{
+ =C2=A0 =C2=A0 =C2=A0for (r =3D mmap_regions; r; r =3D r->next)
+ =C2=A0 =C2=A0 =C2=A0 *r->var =3D NULL;
+ =C2=A0 =C2=A0 =C2=A0mmap_regions_1 =3D mmap_regions;
+ =C2=A0 =C2=A0 =C2=A0mmap_regions =3D NULL;
+ =C2=A0 =C2=A0 =C2=A0mmap_fd_1 =3D mmap_fd;
+ =C2=A0 =C2=A0 =C2=A0mmap_fd =3D -1;
+ =C2=A0 =C2=A0}
+}
+
+
=C2=A0/* Allocate a block of storage large enough to hold NBYTES bytes of =C2=A0 =C2=A0 data. =C2=A0A pointer to the data is returned in *VAR. =C2=A0= VAR is thus the
=C2=A0 =C2=A0 address of some variable which will use the data area.

=3D=3D=3D modified file 'src/emacs.c'
--- src/emacs.c 2014-05-27 17:31:17 +0000
+++ src/emacs.c 2014-05-29 12:28:19 +0000
@@ -2155,8 +2155,13 @@
=C2=A0 =C2=A0malloc_state_ptr =3D malloc_get_state ();
=C2=A0#endif

+#if defined USE_MMAP_FOR_BUFFERS && !defined WINDOWSNT
+ =C2=A0mmap_set_vars (0);
+#endif
=C2=A0 =C2=A0unexec (SSDATA (filename), !NILP (symfile) ? SSDATA (symfile) = : 0);
-
+#if defined USE_MMAP_FOR_BUFFERS && !defined WINDOWSNT
+ =C2=A0mmap_set_vars (1);
+#endif
=C2=A0#ifdef DOUG_LEA_MALLOC
=C2=A0 =C2=A0free (malloc_state_ptr);
=C2=A0#endif


Ken


--20cf303bfebe6ab58204fa8a4583--