bug#17622: 24.4.50; bootstrap failure

bug#17622: 24.4.50; bootstrap failure

[Katsumi Yamaoka]

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'

bug#17622: 24.4.50; bootstrap failure

[Katsumi Yamaoka]

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@entry=0x935118 <bss_sbrk_buffer+1188856>, 
    nbytes=nbytes@entry=46) at buffer.c:4895
4895		r->next->prev = r;
(gdb) bt
#0  mmap_alloc (var=var@entry=0x935118 <bss_sbrk_buffer+1188856>, 
    nbytes=nbytes@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@entry=0x935000 <bss_sbrk_buffer+1188576>, 
    delta=delta@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) 

bug#17622: 24.4.50; bootstrap failure

[Katsumi Yamaoka]

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@entry=0x935118 <bss_sbrk_buffer+1188856>,
>     nbytes=nbytes@entry=46) at buffer.c:4895
> 4895		r->next->prev = r;
> (gdb) bt
> #0  mmap_alloc (var=var@entry=0x935118 <bss_sbrk_buffer+1188856>,
>     nbytes=nbytes@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@entry=0x935000 <bss_sbrk_buffer+1188576>,
>     delta=delta@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)

bug#17622: 24.4.50; bootstrap failure

[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

bug#17622: 24.4.50; bootstrap failure

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

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@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
>

[-- Attachment #2: Type: text/html, Size: 3581 bytes --]

bug#17622: 24.4.50; bootstrap failure

[Ken Brown]

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

bug#17622: 24.4.50; bootstrap failure

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 3612 bytes --]

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@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@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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5179 bytes --]

bug#17622: 24.4.50; bootstrap failure

[Ken Brown]

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

bug#17622: 24.4.50; bootstrap failure

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

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@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
>
>

[-- Attachment #2: Type: text/html, Size: 2731 bytes --]

bug#17622: 24.4.50; bootstrap failure

[Eli Zaretskii]

> Date: Thu, 29 May 2014 13:56:59 +0900
> From: Katsumi Yamaoka <yamaoka@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.

bug#17622: 24.4.50; bootstrap failure

[Eli Zaretskii]

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

bug#17622: 24.4.50; bootstrap failure

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Thu, 29 May 2014 14:55:38 +0200
> Cc: Katsumi Yamaoka <yamaoka@jpl.org>, 17622@debbugs.gnu.org, Eli Zaretskii <eliz@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.

bug#17622: 24.4.50; bootstrap failure

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Thu, 29 May 2014 16:24:12 +0200
> Cc: Katsumi Yamaoka <yamaoka@jpl.org>, 17622 <17622@debbugs.gnu.org>, Eli Zaretskii <eliz@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.

bug#17622: 24.4.50; bootstrap failure

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

Ok, thanks for fixing it in the repo.

Fabrice


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

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Thu, 29 May 2014 16:24:12 +0200
> > Cc: Katsumi Yamaoka <yamaoka@jpl.org>, 17622 <17622@debbugs.gnu.org>,
> Eli Zaretskii <eliz@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.
>

[-- Attachment #2: Type: text/html, Size: 1421 bytes --]

bug#17622: 24.4.50; bootstrap failure

[Katsumi Yamaoka]

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!