Re: Warning starting Emacs (Cygwin)

[Chong Yidong <cyd@stupidchicken.com>]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> The check is very likely fine, I was hoping you understand the code
> the macro guards...  Please see Angelo's messages, he gives a lot of
> details that might ring a bell.

I don't understand the code in check_memory_limits is trying to do.
rlim_cur and rlim_max are the "soft limit" and "hard limit" for the
amount of memory the Emacs process can possibly occupy; so why are we
interested in comparing the two?  There's no guarantee that this has
anything to do with the amount of memory Emacs actually consumes.

(There's also a separate bug: the `cp' variable isn't initialized if
HAVE_GETRLIMIT is defined, even though it is used.)

In short, I think the code is simply based on a misunderstanding of
getrlimit.  The following patch should fix this confusion, by setting
data_size using morecore instead of rlimit.rlim_cur.

However, this raises the separate issue of bug#86, which is that the
real_morecore/__morecore hack causes crashes on HP/UX.  I think this
whole function should be wrapped in a `#if GNU_MALLOC ', at the very
least.  If we're using some unknown malloc implementation, just make it
a no-op.


*** trunk/src/vm-limit.c.~1.23.~	2008-05-14 03:49:59.000000000 -0400
--- trunk/src/vm-limit.c	2008-08-02 16:15:22.000000000 -0400
***************
*** 166,172 ****
      return;
  
    five_percent = rlimit.rlim_max / 20;
-   data_size = rlimit.rlim_cur;
  
  #else /* not HAVE_GETRLIMIT */
  
--- 166,171 ----
***************
*** 174,179 ****
--- 173,180 ----
      get_lim_data ();
    five_percent = lim_data / 20;
  
+ #endif /* not HAVE_GETRLIMIT */
+ 
    /* Find current end of memory and issue warning if getting near max */
  #ifdef REL_ALLOC
    if (real_morecore)
***************
*** 183,190 ****
    cp = (char *) (*__morecore) (0);
    data_size = (char *) cp - (char *) data_space_start;
  
- #endif /* not HAVE_GETRLIMIT */
- 
    if (!warn_function)
      return;
  
--- 184,189 ----