GNU bug report logs -
#17622
24.4.50; bootstrap failure
Previous Next
Reported by: Katsumi Yamaoka <yamaoka <at> jpl.org>
Date: Wed, 28 May 2014 23:47:01 UTC
Severity: normal
Merged with 17624
Found in version 24.4.50
Done: Katsumi Yamaoka <yamaoka <at> jpl.org>
Bug is archived. No further changes may be made.
Full log
Message #25 received at 17622 <at> debbugs.gnu.org (full text, mbox):
[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)]
This bug report was last modified 10 years and 363 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.