This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: emacs and large-address awareness under recent snapshots

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) > newsize);
(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 a theory. Emacs is estimating its heap size as being approximately result+size (i.e., it is assuming its heap is in relatively low memory). Given the value of result, now in the upper half of memory, it tries to compute a heap size (by doubling newsize repeatedly), and thus will double until newsize goes to 0.

If this theory is correct, a base needs to be subtracted.
If that is happening in the BLOCK macro, and if Ken is
right that heapbase is a small value, then that could
well be the problem: heapbase needs to be "reset" to
0x80000000 ...

Regards -- Eliot Moss

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]