Re: emacs and large-address awareness under recent snapshots

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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.

(*) http://pubs.opengroup.org/onlinepubs/9699919799/functions/getrlimit.html

> 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:
> 
> char *
> start_of_data (void)
> {
> #ifdef BSD_SYSTEM
>   extern char etext;
>   return (POINTER)(&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);
> #else
>   extern int data_start;
>   return ((POINTER) &data_start);
> #endif
> }
> 
> 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 on Cygwin?

There is no such way and in theory it's none of the application's
business.  Whatever the above code thinks it does, it has nothing to do
with the problem you reported, as far as I can see.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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