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