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: <4E3EF911.6090301@cornell.edu>
Date: Sun, 07 Aug 2011 16:44:01 -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> <4E3EA497 DOT 7040402 AT cornell DOT edu> <4E3EBAEF DOT 1030004 AT cornell DOT edu> <20110807200222 DOT GK11601 AT calimero DOT vinschen DOT de>
In-Reply-To: <20110807200222.GK11601@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 4:02 PM, Corinna Vinschen wrote:
> On Aug  7 12:18, Ken Brown wrote:
>> On 8/7/2011 10:43 AM, Ken Brown wrote:
>>> On 8/7/2011 7:50 AM, Corinna Vinschen wrote:
>>>>> 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?
>
> You're right, it calls getrlimit(RLIMIT_AS) to get the information of
> the maximum VM size, and Cygwin always returned 0x80000000.  Apparently
> there's some strange test in emacs, which chokes on the fact that a
> memory address is returned which is beyond the maximum address as
> returned by getrlimit(RLIMIT_AS).
>
> What I did now is to change Cygwin to return always RLIM_INFINITY in
> a call to getrlimit(RLIMIT_AS).  This seems to be more correct anyway,
> given the definition in SUSv4(*):
>
>    "If a call to getrlimit() returns RLIM_INFINITY for a resource, it
>     means the implementation shall not enforce limits on that resource."
>
> That's exactly our situation.  There's no enforced limit on the VM,
> other than the size of the VM itself.  Now emacs is happy.

Thanks!

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