X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.7 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_NEUTRAL
X-Spam-Check-By: sourceware.org
Message-ID: <4E4117AF.3030305@cornell.edu>
Date: Tue, 09 Aug 2011 07:19:11 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: emacs and large-address awareness under recent snapshots
References: <20110807200222 DOT GK11601 AT calimero DOT vinschen DOT de> <4E3F13D8 DOT 7090608 AT cornell DOT edu> <4E3FE323 DOT 9020201 AT cornell DOT edu> <20110808155048 DOT GA28218 AT calimero DOT vinschen DOT de> <4E40093D DOT 10107 AT cornell DOT edu> <20110808162556 DOT GM11601 AT calimero DOT vinschen DOT de> <87sjpbhij7 DOT fsf AT Rainer DOT invalid> <4E404424 DOT 9000600 AT cornell DOT edu> <4E40526C DOT 9080605 AT cornell DOT edu> <4E406C21 DOT 7010007 AT cs DOT umass DOT edu> <20110809082652 DOT GA9492 AT calimero DOT vinschen DOT de>
In-Reply-To: <20110809082652.GA9492@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 8/9/2011 4:26 AM, Corinna Vinschen wrote:
> On Aug  8 19:07, Eliot Moss wrote:
>> On 8/8/2011 5:17 PM, Ken Brown wrote:
>>
>>> do
>>> newsize *= 2;
>>> while ((__malloc_size_t) BLOCK ((char *) result + size)>  newsize);
>>>
>>> My guess now is that there was some invalid pointer arithmetic somewhere that led to this, but I
>>> don't have time at the moment to look for it. I'll do it later (or tomorrow) if no one beats me to it.
>>
>> Possibly, Ken. I also wonder about signed vs unsigned calculations
>> and such. We are looking at the higher end of the address space,
>> which means negative addresses when considered as signed numbers.
>>
>> I'm not sure what the above is doing, but if it is trying to
>> double its understanding of the heap size, based on using the
>> current end of the heap (result?) as a measure of size, then
>> if the heap is at 0x80000000, doubling that gives 0 in a 32-bit
>> address space ...
>
> The question is, how could newsize ever become>= 0x80000000?
> Ken, what are the values of result and size?  And what value has
> heapsize?  Consider that the statement before the loop is
>
>    newsize = heapsize;

(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.

Ken

--
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