Message-ID: <4E411B61.1090900@cs.umass.edu>
Date: Tue, 09 Aug 2011 07:34:57 -0400
From: Eliot Moss <moss@cs.umass.edu>
Reply-To: moss@cs.umass.edu
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: emacs and large-address awareness under recent snapshots
References: <20110807200222.GK11601@calimero.vinschen.de> <4E3F13D8.7090608@cornell.edu> <4E3FE323.9020201@cornell.edu> <20110808155048.GA28218@calimero.vinschen.de> <4E40093D.10107@cornell.edu> <20110808162556.GM11601@calimero.vinschen.de> <87sjpbhij7.fsf@Rainer.invalid> <4E404424.9000600@cornell.edu> <4E40526C.9080605@cornell.edu> <4E406C21.7010007@cs.umass.edu> <20110809082652.GA9492@calimero.vinschen.de> <4E4117AF.3030305@cornell.edu>
In-Reply-To: <4E4117AF.3030305@cornell.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

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