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 14:55:38 +0200 Message-ID: References: <53872A40.3020000@cornell.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1135effe4665ab04fa8973dd X-Trace: ger.gmane.org 1401368248 27150 80.91.229.3 (29 May 2014 12:57:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2014 12:57:28 +0000 (UTC) Cc: 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 14:57:21 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 1WpztY-0005Uw-PK for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 May 2014 14:57:21 +0200 Original-Received: from localhost ([::1]:47938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WpztY-0007R4-8i for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 May 2014 08:57:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WpztP-0007O9-RJ for bug-gnu-emacs@gnu.org; Thu, 29 May 2014 08:57:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WpztK-0001ws-1q for bug-gnu-emacs@gnu.org; Thu, 29 May 2014 08:57:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WpztJ-0001wo-VF for bug-gnu-emacs@gnu.org; Thu, 29 May 2014 08:57:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WpztJ-0005gR-8l for bug-gnu-emacs@gnu.org; Thu, 29 May 2014 08:57:05 -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 12:57:04 +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.140136817521766 (code B ref 17622); Thu, 29 May 2014 12:57:04 +0000 Original-Received: (at 17622) by debbugs.gnu.org; 29 May 2014 12:56:15 +0000 Original-Received: from localhost ([127.0.0.1]:35308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WpzsR-0005ev-8s for submit@debbugs.gnu.org; Thu, 29 May 2014 08:56:15 -0400 Original-Received: from mail-ig0-f171.google.com ([209.85.213.171]:46521) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WpzsK-0005eR-8S for 17622@debbugs.gnu.org; Thu, 29 May 2014 08:56:08 -0400 Original-Received: by mail-ig0-f171.google.com with SMTP id c1so3710311igq.4 for <17622@debbugs.gnu.org>; Thu, 29 May 2014 05:55:58 -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=dSKDcqHUKuQVZgT+D/DHezzZu/0MN8s+4tinWqFSIAI=; b=s+k1DrTp4Ey2+EJWngQQfjT325gvUXYnKRE97HFd/i8XeBdJSyTfUYn0xhj8RVS7/6 igV7VVTkqGjtOAJ9dcPhoSw57876foXkNflG/i+ekjfbE9cMXnBncad0dQ7CyCD4HCfi nFmLHKeooC4RvHK6QZ3qH/+Sbh8SVhnrAa2PY8eSodPGX9VlppFWhByHIB5F0CjjEmKk eZH92BPwyghzK2NxB+yLqmXpvo+SecIrfBAcaKy9SY2XuFtj8AxdElJA9yZCrtT0lykZ ZEQ9+rWK41tcKJFhpN7cav6kwSgguF0atg3x5wDo+JtsGWolVxjFABEczqiknSmxovnx 4uKQ== X-Received: by 10.50.143.34 with SMTP id sb2mr10138451igb.11.1401368158297; Thu, 29 May 2014 05:55:58 -0700 (PDT) Original-Received: by 10.64.10.202 with HTTP; Thu, 29 May 2014 05:55:38 -0700 (PDT) In-Reply-To: <53872A40.3020000@cornell.edu> 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:89671 Archived-At: --001a1135effe4665ab04fa8973dd Content-Type: text/plain; charset=UTF-8 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 > --001a1135effe4665ab04fa8973dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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

--001a1135effe4665ab04fa8973dd--