X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.6 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_NEUTRAL
X-Spam-Check-By: sourceware.org
Message-ID: <4E3EA497.7040402@cornell.edu>
Date: Sun, 07 Aug 2011 10:43:35 -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: <4E3C79E0 DOT 3030506 AT cornell DOT edu> <20110807113354 DOT GG11601 AT calimero DOT vinschen DOT de> <20110807115056 DOT GI11601 AT calimero DOT vinschen DOT de>
In-Reply-To: <20110807115056.GI11601@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/7/2011 7:50 AM, Corinna Vinschen wrote:
> On Aug  7 13:33, Corinna Vinschen wrote:
>> On Aug  5 19:16, Ken Brown wrote:
>>> Starting with the 2011-07-21 snapshot, emacs doesn't work well with
>>> the large-address-awareness flag set (under 64-bit Win7).  As soon
>>> as emacs is started, a *Warning* buffer is created with the
>>> following message:
>>>
>>>    Emergency (alloc): Warning: past 95% of memory limit
>>>
>>> To reproduce, install emacs and do the following:
>>>
>>> $ peflags --bigaddr=1 /usr/bin/emacs-nox.exe
>>>
>>> $ emacs-nox.exe -Q
>>
>> Yes, I can reproduce the message, but I have not the faintest idea
>> why emacs thinks so.  If you look into the process map, you'll
>> see the following:
>>
>>    $ ps | grep emacs
>>       280    2852     280       2796    0 11001 13:02:21 /usr/bin/emacs-nox
>>    $ less /proc/280/maps
>>    [...]
>>    80000000-8064E000 rw-p 00000000 0000:0000 0                   [heap]
>>    8064E000-98000000 ===p 0064E000 0000:0000 0                   [heap]
>>
>> Starting with the 2011-07-21 the heap starts at 0x80000000 if the
>> application (and the system) is large address aware.  Even if you
>> dont see the "[heap]" decoration(*), the heap is at that address.
>> What you can see is this:
>>
>> - The heap is located at 0x80000000 and has a size of 384 Megs (the
>>    default start size), up to address 0x98000000.
>>
>> - Only the first 0x64e000 (== 6610944) bytes are allocated so far, so
>>    there are still about 254 Megs left on the heap.
>
> I forgot to explain.  The first line
>
>    80000000-8064E000 rw-p 00000000 0000:0000 0
>
> means that the address area from 80000000 to 8064E000 is commited R/W
> memory.  That's the space for which the application has called sbrk().
>
> In the second line
>
>    8064E000-98000000 ===p 0064E000 0000:0000 0
>
> the "===p" means that the area is reserved, but uncommited.  That's the
> remainder of the current heap, not sbrk'd yet.
>
> Even if that space would have been taken by emacs, the next sbrk would
> have enough space left, since ther space *after* the current heap is
> not reserverd yet, up to some address in the 0xfff00000 space, so there's
> about 1.7 Gigs left to extend the heap.
>
>> I did set breakpoints to all functions returning malloc information,
>> but emacs doesn't call one of them.  Is there a chance that emacs
>> does some invalid 32 bit pointer arithmetic and just gets confused?

Thanks for all the information.

Emacs checks available memory in the function check_memory_limits() in 
the source file src/vm-limits.c.  I'm trying to sort it out, but I don't 
see any invalid pointer arithmetic.  If I'm correctly following all the 
preprocessor logic, emacs uses getrlimit() on Cygwin to determine the 
total memory.  Is it possible that this is returning the wrong value 
when the large-address-awareness flag is set?

I tried to use gdb to step through check_memory_limits() with and 
without the flag set.  But when the flag was set, gdb froze.

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