emacs and large-address awareness under recent snapshots

Ken Brown kbrown@cornell.edu
Sun Aug 7 22:39: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.

I've built cygwin1.dll from the latest CVS and confirmed that the 
problem is fixed.  Unfortunately, I've just discovered a second problem, 
also starting with the 2011-07-21 snapshot, that only shows up when I 
try to start emacs under X (with emacs large address aware).  What 
happens here is that emacs keeps using more and more CPU (as shown by 
Windows Task Manager), but the emacs window never opens.  To reproduce, 
install emacs-X11 and then do the following:

1. $ peflags --bigaddr=1 /usr/bin/emacs-X11.exe

2. Start the X server.  (I use the Start Menu shortcut.)

3. Start emacs from an xterm window:

    $ emacs -Q &

As a slight variation on this, you can instead start emacs with the -nw 

    $ emacs -nw -Q

This tells emacs to use the xterm window for display rather than opening 
its own window.  The result this time is that you can see the emacs 
display, but emacs is unresponsive while the CPU usage increases as before.


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