This is the mail archive of the
mailing list for the Cygwin project.
Re: emacs and large-address awareness under recent snapshots
On 8/7/2011 10:43 AM, Ken Brown wrote:
On 8/7/2011 7:50 AM, Corinna Vinschen wrote:
On Aug 7 13:33, Corinna Vinschen wrote:
On Aug 5 19:16, Ken Brown wrote:
Starting with the 2011-07-21 snapshot, emacs doesn't work well with
the large-address-awareness flag set (under 64-bit Win7). As soon
as emacs is started, a *Warning* buffer is created with the
Emergency (alloc): Warning: past 95% of memory limit
To reproduce, install emacs and do the following:
$ peflags --bigaddr=1 /usr/bin/emacs-nox.exe
$ emacs-nox.exe -Q
Yes, I can reproduce the message, but I have not the faintest idea
why emacs thinks so. If you look into the process map, you'll
see the following:
$ ps | grep emacs
280 2852 280 2796 0 11001 13:02:21 /usr/bin/emacs-nox
$ less /proc/280/maps
80000000-8064E000 rw-p 00000000 0000:0000 0 [heap]
8064E000-98000000 ===p 0064E000 0000:0000 0 [heap]
Starting with the 2011-07-21 the heap starts at 0x80000000 if the
application (and the system) is large address aware. Even if you
dont see the "[heap]" decoration(*), the heap is at that address.
What you can see is this:
- The heap is located at 0x80000000 and has a size of 384 Megs (the
default start size), up to address 0x98000000.
- Only the first 0x64e000 (== 6610944) bytes are allocated so far, so
there are still about 254 Megs left on the heap.
I forgot to explain. The first line
80000000-8064E000 rw-p 00000000 0000:0000 0
means that the address area from 80000000 to 8064E000 is commited R/W
memory. That's the space for which the application has called sbrk().
In the second line
8064E000-98000000 ===p 0064E000 0000:0000 0
the "===p" means that the area is reserved, but uncommited. That's the
remainder of the current heap, not sbrk'd yet.
Even if that space would have been taken by emacs, the next sbrk would
have enough space left, since ther space *after* the current heap is
not reserverd yet, up to some address in the 0xfff00000 space, so there's
about 1.7 Gigs left to extend the heap.
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?
I tried to use gdb to step through check_memory_limits() with and
without the flag set. But when the flag was set, gdb froze.
I may have found the problem. I think emacs is not correctly
determining the start of the heap, with or without large address
awareness. When I run emacs under gdb (without large address
awareness), I find that emacs thinks the heap starts at 0x7b6b30. But
the heap actually starts at 0x20000000, doesn't it?
Here's the code that emacs uses to find the start of the heap:
extern char etext;
#elif defined DATA_START
return ((POINTER) DATA_START);
#elif defined ORDINARY_LINK
* This is a hack. Since we're not linking crt0.c or pre_crt0.c,
* data_start isn't defined. We take the address of environ, which
* is known to live at or near the start of the system crt0.c, and
* we don't sweat the handful of bytes that might lose.
extern char **environ;
return ((POINTER) &environ);
extern int data_start;
return ((POINTER) &data_start);
I left all the preprocessor stuff in there to play it safe, but I think
we're in the ORDINARY_LINK case.
What would be the right way for emacs to determine the start of the heap
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple