From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Warning starting Emacs (Cygwin) Date: Sat, 02 Aug 2008 16:19:51 -0400 Message-ID: <87k5ezcgpk.fsf@stupidchicken.com> References: <4891D01B.6070802@alice.it> <4891E7E8.1000503@alice.it> <200807311700.m6VH0eCa004994@sallyv1.ics.uci.edu> <4892E7BE.1080706@alice.it> <489306EE.7090800@alice.it> <200808011308.m71D8PA3023871@sallyv1.ics.uci.edu> <489319F7.5040101@alice.it> <200808011436.m71EaAeZ019293@sallyv1.ics.uci.edu> <4893765E.5020803@alice.it> <200808020406.m7246D1T003058@sallyv1.ics.uci.edu> <48946F36.3020505@alice.it> <200808021859.m72IxGnr000877@sallyv1.ics.uci.edu> <87wsiz1b6l.fsf@stupidchicken.com> <200808021930.m72JUTrw014872@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1217708394 10142 80.91.229.12 (2 Aug 2008 20:19:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Aug 2008 20:19:54 +0000 (UTC) Cc: emacs-devel@gnu.org, Angelo Graziosi To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 02 22:20:44 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KPNal-00024M-VJ for ged-emacs-devel@m.gmane.org; Sat, 02 Aug 2008 22:20:44 +0200 Original-Received: from localhost ([127.0.0.1]:48790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KPNZr-0005sD-5V for ged-emacs-devel@m.gmane.org; Sat, 02 Aug 2008 16:19:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KPNZm-0005ou-Kp for emacs-devel@gnu.org; Sat, 02 Aug 2008 16:19:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KPNZl-0005mX-JR for emacs-devel@gnu.org; Sat, 02 Aug 2008 16:19:41 -0400 Original-Received: from [199.232.76.173] (port=53472 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KPNZl-0005m2-A3 for emacs-devel@gnu.org; Sat, 02 Aug 2008 16:19:41 -0400 Original-Received: from cyd.mit.edu ([18.115.2.24]:47657 helo=cyd) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KPNZk-00020T-Ph for emacs-devel@gnu.org; Sat, 02 Aug 2008 16:19:41 -0400 Original-Received: by cyd (Postfix, from userid 1000) id 91E4B57E337; Sat, 2 Aug 2008 16:19:51 -0400 (EDT) In-Reply-To: <200808021930.m72JUTrw014872@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Sat, 02 Aug 2008 12:30:29 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:101971 Archived-At: Dan Nicolaescu 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 ----