This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: emacs and large-address awareness under recent snapshots

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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]