emacs and large-address awareness under recent snapshots

Ken Brown kbrown@cornell.edu
Sun Aug 7 20:44:00 GMT 2011

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.



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

More information about the Cygwin mailing list