Mail Archives: cygwin/2011/08/07/16:44:36
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
- Raw text -