[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9273: 23.3; malloc initialization should (sometimes) happen at runti
From: |
Ken Brown |
Subject: |
bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime |
Date: |
Sat, 13 Aug 2011 23:13:39 -0400 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 |
On 8/13/2011 3:19 PM, Stefan Monnier wrote:
>> Probably. That would keep me from having to get involved in the details of
>> how _heapinfo works, and it would probably be less error prone. So I would
>> do something like the following:
>
>> 1. Temporarily restore the pre-dump malloc state.
>> 2. Call xrealloc, getting storage of the new size in the old heap.
>> 3. Copy the contents into a temporary buffer, and then free the recently
>> allocated storage in the old heap.
>> 4. Restore the malloc state, call malloc, and then copy the contents of the
>> temporary buffer into the just-acquired storage in the new heap.
>
>> Is that what you had in mind?
>
> No, I meant, during initialization of Emacs, make sure we get the old
> _heapinfo state, so that malloc/realloc/... just works.
No, that wouldn't be good because the old _heapinfo state uses the static heap,
which is very small. It's big enough for temacs, but not for a usable emacs.
In any case, Eli's suggestion turned out to be very easy to implement. My
revised patch is appended below, and it seems to solve all the problems I
encountered. I still want to test it further, but I think it's OK. Eli,
thanks for your help.
Ken
=== modified file 'src/gmalloc.c'
--- src/gmalloc.c 2011-08-04 17:04:39 +0000
+++ src/gmalloc.c 2011-08-13 22:32:45 +0000
@@ -351,11 +351,19 @@
#endif
#include <errno.h>
-/* How to really get more memory. */
-#if defined(CYGWIN)
+/* On Cygwin there are two heaps. temacs uses the static heap
+ (defined in sheap.c and managed with bss_sbrk), and the dumped
+ emacs uses the Cygwin heap (managed with sbrk). When emacs starts
+ on Cygwin, it reinitializes malloc, and we save the old info for
+ use by free and realloc if they're called with a pointer into the
+ static heap. */
+#ifdef CYGWIN
extern __ptr_t bss_sbrk PP ((ptrdiff_t __size));
extern int bss_sbrk_did_unexec;
+char *bss_sbrk_heapbase;
+malloc_info *bss_sbrk_heapinfo;
#endif
+
__ptr_t (*__morecore) PP ((__malloc_ptrdiff_t __size)) = __default_morecore;
/* Debugging hook for `malloc'. */
@@ -584,6 +592,16 @@
mcheck (NULL);
#endif
+#ifdef CYGWIN
+ if (bss_sbrk_did_unexec)
+ /* we're reinitializing the dumped emacs */
+ {
+ bss_sbrk_heapbase = _heapbase;
+ bss_sbrk_heapinfo = _heapinfo;
+ memset (_fraghead, 0, BLOCKLOG * sizeof (struct list));
+ }
+#endif
+
if (__malloc_initialize_hook)
(*__malloc_initialize_hook) ();
@@ -1054,6 +1072,12 @@
if (ptr == NULL)
return;
+#ifdef CYGWIN
+ if (ptr < _heapbase)
+ /* We're being asked to free something in the static heap. */
+ return;
+#endif
+
PROTECT_MALLOC_STATE (0);
LOCK_ALIGNED_BLOCKS ();
@@ -1346,9 +1370,33 @@
#include <malloc.h>
#endif
-
#define min(A, B) ((A) < (B) ? (A) : (B))
+/* On Cygwin the dumped emacs may try to realloc storage allocated in
+ the static heap. We just malloc space in the new heap and copy the
+ data. */
+#ifdef CYGWIN
+__ptr_t
+special_realloc (ptr, size)
+ __ptr_t ptr;
+ __malloc_size_t size;
+{
+ __ptr_t result;
+ int type;
+ __malloc_size_t block, oldsize;
+
+ block = ((char *) ptr - bss_sbrk_heapbase) / BLOCKSIZE + 1;
+ type = bss_sbrk_heapinfo[block].busy.type;
+ oldsize =
+ type == 0 ? bss_sbrk_heapinfo[block].busy.info.size * BLOCKSIZE
+ : (__malloc_size_t) 1 << type;
+ result = _malloc_internal_nolock (size);
+ if (result != NULL)
+ memcpy (result, ptr, min (oldsize, size));
+ return result;
+}
+#endif
+
/* Debugging hook for realloc. */
__ptr_t (*__realloc_hook) PP ((__ptr_t __ptr, __malloc_size_t __size));
@@ -1375,6 +1423,12 @@
else if (ptr == NULL)
return _malloc_internal_nolock (size);
+#ifdef CYGWIN
+ if (ptr < _heapbase)
+ /* ptr points into the static heap */
+ return special_realloc (ptr, size);
+#endif
+
block = BLOCK (ptr);
PROTECT_MALLOC_STATE (0);
=== modified file 'src/unexcw.c'
--- src/unexcw.c 2011-03-17 20:18:59 +0000
+++ src/unexcw.c 2011-08-12 20:10:03 +0000
@@ -33,6 +33,8 @@
extern int bss_sbrk_did_unexec;
+extern int __malloc_initialized;
+
/* emacs symbols that indicate where bss and data end for emacs internals */
extern char my_endbss[];
extern char my_edata[];
@@ -210,9 +212,12 @@
lseek (fd, (long) (exe_header->section_header[i].s_scnptr),
SEEK_SET);
assert (ret != -1);
+ /* force the dumped emacs to reinitialize malloc */
+ __malloc_initialized = 0;
ret =
write (fd, (char *) start_address,
my_endbss - (char *) start_address);
+ __malloc_initialized = 1;
assert (ret == (my_endbss - (char *) start_address));
if (debug_unexcw)
printf (" .bss, mem start 0x%08x mem length %d\n",
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, (continued)
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Eli Zaretskii, 2011/08/12
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Ken Brown, 2011/08/12
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Ken Brown, 2011/08/12
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Eli Zaretskii, 2011/08/13
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Ken Brown, 2011/08/13
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Eli Zaretskii, 2011/08/13
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Ken Brown, 2011/08/13
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Stefan Monnier, 2011/08/13
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Ken Brown, 2011/08/13
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Stefan Monnier, 2011/08/13
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime,
Ken Brown <=
- bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, Ken Brown, 2011/08/16
bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime, grischka, 2011/08/12