This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple