emacs and large-address awareness under recent snapshots
Tue Aug 9 14:13:00 GMT 2011
On 8/9/2011 7:19 AM, Ken Brown wrote:
> (gdb) thread 1
> [Switching to thread 1 (Thread 19828.0x447c)]
> #0 0x00622ee0 in morecore_nolock (size=1052672) at gmalloc.c:703
> 703 while ((__malloc_size_t) BLOCK ((char *) result + size)>
> (gdb) p /x size
> $1 = 0x101000
> (gdb) p /x heapsize
> $2 = 0x80000
> (gdb) p result
> $3 = (void *) 0x807d0000
> (gdb) p newsize
> $4 = 0
> (gdb) p _heapbase
> $5 = 0x816000 "\202"
> (gdb) p _heapinfo
> $6 = (malloc_info *) 0x80060000
> Is _heapbase the problem? This is initialized to _heapinfo at the first
> call of malloc and is never changed. _heapinfo presumably points into
> the static heap at that point. (_heapinfo is later changed as a result
> of realloc.) This low value of _heapbase is used in the BLOCK macro.
Here's what I think is happening. When temacs.exe is running during the
build process (see my explanation of this earlier in the thread),
malloc_init is called and _heapbase is set. At this point, temacs is
using its own static buffer as the heap, and _heapbase gets the value
0x816000. This gets dumped as initialized data into emacs.exe, as does
the value __malloc_initialized = 1. Now when emacs.exe is run, it sees
that malloc has already been initialized, so _heapbase retains its
value, which is no longer appropriate. All code relying on the BLOCK
macro is now invalid.
AFAICS, this has always been wrong. But the error didn't have dramatic
consequences until the heap was put into high memory.
I'm not sure what's the best way to fix this (assuming my analysis is
right). Would it be enough to set __malloc_initialized to 0 before
dumping? That would force emacs to reinitialize and get the correct
value of _heapbase.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin