emacs and large-address awareness under recent snapshots

[Eliot Moss]

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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple