GNU bug report logs - #17622
24.4.50; bootstrap failure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17622 in the body.
You can then email your comments to 17622 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 08:45:40 +0900

Hi,

Bootstrap fails since yesterday.  I have no clue for this but
bootstrap-emacs seems to do nothing and to quit silently.

,---- (Note: there is no `Wrote *.elc' message.)
| [...]
| Dumping under the name emacs
| Maximum static heap usage: 10470112 of 13631488 bytes
| 46131 pure bytes used
| cd ../lisp; make -w compile-first EMACS="../src/bootstrap-emacs.exe"
| make[3]: Entering directory '/Work/Emacs/lisp'
| Compiling emacs-lisp/macroexp.el
| Compiling emacs-lisp/cconv.el
| Compiling emacs-lisp/byte-opt.el
| Compiling emacs-lisp/bytecomp.el
| Compiling emacs-lisp/autoload.el
| [...]
`----

Is there a thing I should do next?  Thanks.

In GNU Emacs 24.4.50.1 (i686-pc-cygwin, GTK+ Version 3.10.7)
 of TODAY on localhost
Repository revision: LATEST
Windowing system distributor `The Cygwin/X Project', version 11.0.11501000
Configured using:
 `configure --verbose --with-x-toolkit=gtk3'

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: 17622 <at> debbugs.gnu.org
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 11:02:32 +0900

A gdb backtrace is attached below.

On Thu, 29 May 2014 08:45:40 +0900, Katsumi Yamaoka wrote:
> Bootstrap fails since yesterday.  I have no clue for this but
> bootstrap-emacs seems to do nothing and to quit silently.

> ,---- (Note: there is no `Wrote *.elc' message.)
>| [...]
>| Dumping under the name emacs
>| Maximum static heap usage: 10470112 of 13631488 bytes
>| 46131 pure bytes used
>| cd ../lisp; make -w compile-first EMACS="../src/bootstrap-emacs.exe"
>| make[3]: Entering directory '/Work/Emacs/lisp'
>| Compiling emacs-lisp/macroexp.el
>| Compiling emacs-lisp/cconv.el
>| Compiling emacs-lisp/byte-opt.el
>| Compiling emacs-lisp/bytecomp.el
>| Compiling emacs-lisp/autoload.el
>| [...]
> `----

$ gdb ./bootstrap-emacs.exe
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
..
Reading symbols from /Work/Emacs/src/bootstrap-emacs.exe...done.
warning: File "/Work/Emacs/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /Work/Emacs/src/.gdbinit
line to your configuration file "/home/yamaoka/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/yamaoka/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
^[[?1034h(gdb) r
Starting program: /Work/Emacs/src/bootstrap-emacs.exe 
[New Thread 11900.0x28f8]
[New Thread 11900.0x2d58]

Program received signal SIGSEGV, Segmentation fault.
mmap_alloc (var=var <at> entry=0x935118 <bss_sbrk_buffer+1188856>, 
    nbytes=nbytes <at> entry=46) at buffer.c:4895
4895		r->next->prev = r;
(gdb) bt
#0  mmap_alloc (var=var <at> entry=0x935118 <bss_sbrk_buffer+1188856>, 
    nbytes=nbytes <at> entry=46) at buffer.c:4895
#1  0x004e23a9 in mmap_realloc (nbytes=46, 
    var=0x935118 <bss_sbrk_buffer+1188856>) at buffer.c:4934
#2  enlarge_buffer_text (b=b <at> entry=0x935000 <bss_sbrk_buffer+1188576>, 
    delta=delta <at> entry=0) at buffer.c:5042
#3  0x004e397d in init_buffer () at buffer.c:5290
#4  0x005b2d2f in main (argc=1, argv=0x22ac1c) at emacs.c:1379
(gdb) q
A debugging session is active.

	Inferior 1 [process 11900] will be killed.

Quit anyway? (y or n) 

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: 17622 <at> debbugs.gnu.org
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 13:56:59 +0900

I verified simply reverting r117168 builds Emacs successfully on
Cygwin.

On Thu, 29 May 2014 11:02:32 +0900, Katsumi Yamaoka wrote:
> A gdb backtrace is attached below.

> On Thu, 29 May 2014 08:45:40 +0900, Katsumi Yamaoka wrote:
>> Bootstrap fails since yesterday.  I have no clue for this but
>> bootstrap-emacs seems to do nothing and to quit silently.

>> ,---- (Note: there is no `Wrote *.elc' message.)
>>| [...]
>>| Dumping under the name emacs
>>| Maximum static heap usage: 10470112 of 13631488 bytes
>>| 46131 pure bytes used
>>| cd ../lisp; make -w compile-first EMACS="../src/bootstrap-emacs.exe"
>>| make[3]: Entering directory '/Work/Emacs/lisp'
>>| Compiling emacs-lisp/macroexp.el
>>| Compiling emacs-lisp/cconv.el
>>| Compiling emacs-lisp/byte-opt.el
>>| Compiling emacs-lisp/bytecomp.el
>>| Compiling emacs-lisp/autoload.el
>>| [...]
>> `----

> $ gdb ./bootstrap-emacs.exe
> GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> ..
> Reading symbols from /Work/Emacs/src/bootstrap-emacs.exe...done.
> warning: File "/Work/Emacs/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> To enable execution of this file add
> 	add-auto-load-safe-path /Work/Emacs/src/.gdbinit
> line to your configuration file "/home/yamaoka/.gdbinit".
> To completely disable this security protection add
> 	set auto-load safe-path /
> line to your configuration file "/home/yamaoka/.gdbinit".
> For more information about this security protection see the
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
> 	info "(gdb)Auto-loading safe path"
> ^[[?1034h(gdb) r
> Starting program: /Work/Emacs/src/bootstrap-emacs.exe
> [New Thread 11900.0x28f8]
> [New Thread 11900.0x2d58]

> Program received signal SIGSEGV, Segmentation fault.
> mmap_alloc (var=var <at> entry=0x935118 <bss_sbrk_buffer+1188856>,
>     nbytes=nbytes <at> entry=46) at buffer.c:4895
> 4895		r->next->prev = r;
> (gdb) bt
> #0  mmap_alloc (var=var <at> entry=0x935118 <bss_sbrk_buffer+1188856>,
>     nbytes=nbytes <at> entry=46) at buffer.c:4895
> #1  0x004e23a9 in mmap_realloc (nbytes=46,
>     var=0x935118 <bss_sbrk_buffer+1188856>) at buffer.c:4934
> #2  enlarge_buffer_text (b=b <at> entry=0x935000 <bss_sbrk_buffer+1188576>,
>     delta=delta <at> entry=0) at buffer.c:5042
> #3  0x004e397d in init_buffer () at buffer.c:5290
> #4  0x005b2d2f in main (argc=1, argv=0x22ac1c) at emacs.c:1379
> (gdb) q
> A debugging session is active.

> 	Inferior 1 [process 11900] will be killed.

> Quit anyway? (y or n)

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>, 17622 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 08:38:24 -0400

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

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

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 17622 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 14:55:38 +0200

[Message part 1 (text/plain, inline)]

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 <kbrown <at> 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.  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
>

[Message part 2 (text/html, inline)]

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 17622 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 09:29:10 -0400

On 5/29/2014 8:55 AM, Fabrice Popineau wrote:
> 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.

I'm not familiar enough with this code to start making changes.  If you 
think you see a way to fix the bug that's better than reinstating 
mmap_set_vars, please just do it.

Thanks.

Ken

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

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 17622 <17622 <at> debbugs.gnu.org>, Katsumi Yamaoka <yamaoka <at> jpl.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 15:54:23 +0200

[Message part 1 (text/plain, inline)]

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 <fabrice.popineau <at> gmail.com>:

> 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 <kbrown <at> 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.  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
>>
>
>

[Message part 2 (text/html, inline)]

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 17622 <17622 <at> debbugs.gnu.org>, Katsumi Yamaoka <yamaoka <at> jpl.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 10:17:39 -0400

On 5/29/2014 9:54 AM, Fabrice Popineau wrote:
> 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!).

Confirmed.  Thanks.

Ken

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

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 17622 <17622 <at> debbugs.gnu.org>, Katsumi Yamaoka <yamaoka <at> jpl.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 16:24:12 +0200

[Message part 1 (text/plain, inline)]

Thanks, albeit I missed the obvious.

=== modified file 'src/buffer.c'
--- src/buffer.c        2014-05-27 17:31:17 +0000
+++ src/buffer.c        2014-05-29 14:22:37 +0000
@@ -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,10 @@
   {
     struct buffer *b;

+#ifndef WINDOWSNT
+    mmap_regions = NULL;
+    mmap_fd = -1;
+#endif
     /* 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)

Fabrice


2014-05-29 16:17 GMT+02:00 Ken Brown <kbrown <at> cornell.edu>:

> On 5/29/2014 9:54 AM, Fabrice Popineau wrote:
>
>> 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!).
>>
>
> Confirmed.  Thanks.
>
> Ken
>
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 17622 <at> debbugs.gnu.org
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 17:59:39 +0300

> Date: Thu, 29 May 2014 13:56:59 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> 
> I verified simply reverting r117168 builds Emacs successfully on
> Cygwin.

Yes, that revision, together with a lot of bathwater, threw out a bit
of the baby.  Sorry about that.  Please try the latest trunk.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 17622 <at> debbugs.gnu.org, yamaoka <at> jpl.org, fabrice.popineau <at> gmail.com
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 18:08:39 +0300

> Date: Thu, 29 May 2014 08:38:24 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: Eli Zaretskii <eliz <at> gnu.org>,
>         Fabrice Popineau <fabrice.popineau <at> gmail.com>
> 
> 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?

Yes, but there's no need to return all this cruft, as most of it is
not needed.  We only need to reset mmap_regions and mmap_fd.

I installed a patch just now that should fix the crashes, please take
a look.  (It also removes two unused variables, and fixes the
initialization of buffer text in init_buffer, which was slightly
wrong.)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 17622 <at> debbugs.gnu.org, yamaoka <at> jpl.org, kbrown <at> cornell.edu
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 18:09:43 +0300

> From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> Date: Thu, 29 May 2014 14:55:38 +0200
> Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 17622 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> 
> but I wonder if it couldn't be handled at the beginning of
> bufffer.c:init_buffer() instead.

That's what I did, except that we should only do that in emacs, not in
temacs, so init_buffer now accepts a flag variable to achieve that.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 17622 <at> debbugs.gnu.org, yamaoka <at> jpl.org, kbrown <at> cornell.edu
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 18:12:40 +0300

> From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> Date: Thu, 29 May 2014 16:24:12 +0200
> Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 17622 <17622 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
> 
> @@ -5282,6 +5277,10 @@
>    {
>      struct buffer *b;
> 
> +#ifndef WINDOWSNT
> +    mmap_regions = NULL;
> +    mmap_fd = -1;
> +#endif
>      /* 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)

That's what I did, except that this (and the FOR_EACH_BUFFER loop
after it) should only be done in the dumped emacs.

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

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17622 <17622 <at> debbugs.gnu.org>, Katsumi Yamaoka <yamaoka <at> jpl.org>,
 Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Thu, 29 May 2014 18:44:32 +0200

[Message part 1 (text/plain, inline)]

Ok, thanks for fixing it in the repo.

Fabrice


2014-05-29 17:12 GMT+02:00 Eli Zaretskii <eliz <at> gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> > Date: Thu, 29 May 2014 16:24:12 +0200
> > Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 17622 <17622 <at> debbugs.gnu.org>,
> Eli Zaretskii <eliz <at> gnu.org>
> >
> > @@ -5282,6 +5277,10 @@
> >    {
> >      struct buffer *b;
> >
> > +#ifndef WINDOWSNT
> > +    mmap_regions = NULL;
> > +    mmap_fd = -1;
> > +#endif
> >      /* 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)
>
> That's what I did, except that this (and the FOR_EACH_BUFFER loop
> after it) should only be done in the dumped emacs.
>

[Message part 2 (text/html, inline)]

Message #53 received at 17622-done <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: 17622-done <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Fabrice Popineau <fabrice.popineau <at> gmail.com>,
 Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#17622: 24.4.50; bootstrap failure
Date: Fri, 30 May 2014 07:52:02 +0900

On Thu, 29 May 2014 18:44:32 +0200, Fabrice Popineau wrote:
> Ok, thanks for fixing it in the repo.

I got Emacs that runs as normal.  Thanks to all!

Previous Next

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