From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Donald Ephraim Curtis Newsgroups: gmane.emacs.devel Subject: Re: Compilation error caused by SPARE_MEMORY Date: Mon, 6 Jun 2011 07:02:40 -0500 Message-ID: References: <9n62ok6j1i.fsf@fencepost.gnu.org> <4DEC5EA8.6000904@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1307361981 2585 80.91.229.12 (6 Jun 2011 12:06:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Jun 2011 12:06:21 +0000 (UTC) Cc: 8800-done@debbugs.gnu.org, Emacs Development To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 06 14:06:10 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QTYZJ-000305-V1 for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2011 14:06:06 +0200 Original-Received: from localhost ([::1]:44922 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTYZI-0001lX-Sv for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2011 08:06:05 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTYWG-0000zx-3v for Emacs-devel@gnu.org; Mon, 06 Jun 2011 08:02:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTYWE-0005Fy-Bj for Emacs-devel@gnu.org; Mon, 06 Jun 2011 08:02:55 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:64636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTYW9-0005Eo-Hc; Mon, 06 Jun 2011 08:02:49 -0400 Original-Received: by iyl8 with SMTP id 8so3541121iyl.0 for ; Mon, 06 Jun 2011 05:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=5Kn7BqPxwUzJuYQOluuBTJg6CHuUa0uzJ3WRMq/dBdI=; b=tYGhnq6p8X52oVZ2Ye8m4/eEmBG9zi7nJnnijmpyHtees3yKwCb6Wn5nSouzQc6qKc RAu4dzKICz2UaXzQcvoJYZ5yQ1Kzmd9YXlOgFF2MnyQ/29YiljPjXQ9/D1DWdEdIphsZ DrUarcjS6O/n7geW/sMRMHK1wVuM+7dKEV1us= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=US8WGC1E+vaZTLBGEhG8zCDAWHaQatf9SXadkpFX2qdLYpGrY5Hv3G9jFpgqJbEPVg RZIw5XiIZxXWrn/JmJsym5cypjAhg/8e8GEa83heORb1FgBF9rY5HqZACjlNIlmqVBJ3 /TJp/IX5sD+hLfC4FTNKkxmUmFocDBDHLU2J4= Original-Received: by 10.42.6.10 with SMTP id 10mr6047192icy.58.1307361767574; Mon, 06 Jun 2011 05:02:47 -0700 (PDT) Original-Received: from [192.168.1.104] (173-30-221-186.client.mchsi.com [173.30.221.186]) by mx.google.com with ESMTPS id y1sm2723548ica.4.2011.06.06.05.02.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2011 05:02:46 -0700 (PDT) In-Reply-To: <4DEC5EA8.6000904@cs.ucla.edu> X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140228 Archived-At: I'm sorry, I've looked at the code currently in alloc.c (revision = 104510) and I don't see how this is doing anything other than defining = LARGE_REQUEST as (1 << 14) Here is the relevant code: /* Amount of spare memory to keep in large reserve block. */ #define SPARE_MEMORY (1 << 14) #ifdef SYSTEM_MALLOC # define LARGE_REQUEST (1 << 14) #else # define LARGE_REQUEST SPARE_MEMORY #endif But shouldn't there still be a check to see if SPARE_MEMORY is defined = already? On Jun 5, 2011, at 23:59, Paul Eggert wrote: > On 06/05/11 14:54, Glenn Morris wrote: >=20 >> As reported in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D8800 >=20 > Thanks, that is a bug I recently introduced; it affects hosts such > as MacOS that define SYSTEM_MALLOC. I fixed it in the trunk with > bzr 104508, as follows: >=20 > =3D=3D=3D modified file 'src/ChangeLog' > --- src/ChangeLog 2011-06-05 22:46:26 +0000 > +++ src/ChangeLog 2011-06-06 04:54:23 +0000 > @@ -1,3 +1,11 @@ > +2011-06-06 Paul Eggert > + > + * alloc.c (memory_full) [SYSTEM_MALLOC]: Port to MacOS = (Bug#8800). > + Do not assume that spare memory exists; that assumption is valid > + only if SYSTEM_MALLOC. > + (LARGE_REQUEST): New macro, so that the issue of large requests > + is separated from the issue of spare memory. > + > 2011-06-05 Andreas Schwab >=20 > * editfns.c (Fformat): Correctly handle zero flag with = hexadecimal >=20 > =3D=3D=3D modified file 'src/alloc.c' > --- src/alloc.c 2011-06-02 08:35:28 +0000 > +++ src/alloc.c 2011-06-06 04:54:23 +0000 > @@ -196,6 +196,12 @@ > #define SPARE_MEMORY (1 << 14) > #endif >=20 > +#ifdef SYSTEM_MALLOC > +# define LARGE_REQUEST (1 << 14) > +#else > +# define LARGE_REQUEST SPARE_MEMORY > +#endif > + > /* Number of extra blocks malloc should get when it needs more core. = */ >=20 > static int malloc_hysteresis; > @@ -3283,15 +3289,12 @@ > { > /* Do not go into hysterics merely because a large request failed. = */ > int enough_free_memory =3D 0; > - if (SPARE_MEMORY < nbytes) > + if (LARGE_REQUEST < nbytes) > { > - void *p =3D malloc (SPARE_MEMORY); > + void *p =3D malloc (LARGE_REQUEST); > if (p) > { > - if (spare_memory[0]) > - free (p); > - else > - spare_memory[0] =3D p; > + free (p); > enough_free_memory =3D 1; > } > } >=20 >=20