GNU bug report logs - #8800
24.0.50: At revno: 104484 alloc.c does not compile

Previous Next

Package: emacs;

Reported by: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>

Date: Sat, 4 Jun 2011 10:35:01 UTC

Severity: normal

Found in version 24.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8800 in the body.
You can then email your comments to 8800 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8800; Package emacs. (Sat, 04 Jun 2011 10:35:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Dyballa <Peter_Dyballa <at> Freenet.DE>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 04 Jun 2011 10:35:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50: At revno: 104484 alloc.c does not compile
Date: Sat, 4 Jun 2011 12:34:04 +0200
Hello!

The is the report of GCC 4.5.2:

alloc.c: In function ‘memory_full’:
alloc.c:3286:7: error: ‘SPARE_MEMORY’ undeclared (first use in this  
function)
alloc.c:3286:7: note: each undeclared identifier is reported only once  
for each function it appears in

In src/alloc.c I have:

  187	/* Points to memory space allocated as "spare", to be freed if  
we run
  188	   out of memory.  We keep one large block, four cons-blocks, and
  189	   two string blocks.  */
  190	
  191	static char *spare_memory[7];
  192	
  193	#ifndef SYSTEM_MALLOC
  194	/* Amount of spare memory to keep in large reserve block.  */
  195	
  196	#define SPARE_MEMORY (1 << 14)
  197	#endif

In src/config.h I have, around line #1060:

	#define SYSTEM_MALLOC 1

so SPARE_MEMORY does not get defined.

--
Greetings

  Pete

And always remember the last words of my grandfather, who said: “A  
truck!”
				— Emo Phillips





Reply sent to Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility. (Mon, 06 Jun 2011 05:00:04 GMT) Full text and rfc822 format available.

Notification sent to Peter Dyballa <Peter_Dyballa <at> Freenet.DE>:
bug acknowledged by developer. (Mon, 06 Jun 2011 05:00:04 GMT) Full text and rfc822 format available.

Message #10 received at 8800-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 8800-done <at> debbugs.gnu.org, Emacs Development <Emacs-devel <at> gnu.org>
Subject: Re: Compilation error caused by SPARE_MEMORY
Date: Sun, 05 Jun 2011 21:59:20 -0700
On 06/05/11 14:54, Glenn Morris wrote:

> As reported in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8800

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:

=== 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  <eggert <at> cs.ucla.edu>
+
+	* 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  <schwab <at> linux-m68k.org>
 
 	* editfns.c (Fformat): Correctly handle zero flag with hexadecimal

=== 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
 
+#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.  */
 
 static int malloc_hysteresis;
@@ -3283,15 +3289,12 @@
 {
   /* Do not go into hysterics merely because a large request failed.  */
   int enough_free_memory = 0;
-  if (SPARE_MEMORY < nbytes)
+  if (LARGE_REQUEST < nbytes)
     {
-      void *p = malloc (SPARE_MEMORY);
+      void *p = malloc (LARGE_REQUEST);
       if (p)
 	{
-	  if (spare_memory[0])
-	    free (p);
-	  else
-	    spare_memory[0] = p;
+	  free (p);
 	  enough_free_memory = 1;
 	}
     }





Message #11 received at 8800-done <at> debbugs.gnu.org (full text, mbox):

From: Donald Ephraim Curtis <dcurtis <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, 8800-done <at> debbugs.gnu.org,
	Emacs Development <Emacs-devel <at> gnu.org>
Subject: Re: Compilation error caused by SPARE_MEMORY
Date: Mon, 6 Jun 2011 07:02:40 -0500
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:
> 
>> As reported in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8800
> 
> 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:
> 
> === 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  <eggert <at> cs.ucla.edu>
> +
> +	* 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  <schwab <at> linux-m68k.org>
> 
> 	* editfns.c (Fformat): Correctly handle zero flag with hexadecimal
> 
> === 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
> 
> +#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.  */
> 
> static int malloc_hysteresis;
> @@ -3283,15 +3289,12 @@
> {
>   /* Do not go into hysterics merely because a large request failed.  */
>   int enough_free_memory = 0;
> -  if (SPARE_MEMORY < nbytes)
> +  if (LARGE_REQUEST < nbytes)
>     {
> -      void *p = malloc (SPARE_MEMORY);
> +      void *p = malloc (LARGE_REQUEST);
>       if (p)
> 	{
> -	  if (spare_memory[0])
> -	    free (p);
> -	  else
> -	    spare_memory[0] = p;
> +	  free (p);
> 	  enough_free_memory = 1;
> 	}
>     }
> 
> 





Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8800; Package emacs. (Mon, 06 Jun 2011 16:43:02 GMT) Full text and rfc822 format available.

Message #14 received at 8800 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Donald Ephraim Curtis <dcurtis <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 8800 <at> debbugs.gnu.org,
	Emacs Development <Emacs-devel <at> gnu.org>
Subject: Re: Compilation error caused by SPARE_MEMORY
Date: Mon, 06 Jun 2011 09:42:29 -0700
On 06/06/11 05:02, Donald Ephraim Curtis wrote:
> shouldn't there still be a check to see if SPARE_MEMORY is defined already?

If SYSTEM_MALLOC is not defined, SPARE_MEMORY must be defined,
so the code is OK.  This can be seen by looking at the larger context
in alloc.c.  However, I can see that the code is confusing, so
I simplified it this way:

* alloc.c: Simplify handling of large-request failures (Bug#8800).
(SPARE_MEMORY): Always define.
(LARGE_REQUEST): Remove.
(memory_full): Use SPARE_MEMORY rather than LARGE_REQUEST.
=== modified file 'src/alloc.c'
--- src/alloc.c	2011-06-06 04:54:23 +0000
+++ src/alloc.c	2011-06-06 16:39:06 +0000
@@ -190,17 +190,10 @@

 static char *spare_memory[7];

-#ifndef SYSTEM_MALLOC
-/* Amount of spare memory to keep in large reserve block.  */
+/* Amount of spare memory to keep in large reserve block, or to see
+   whether this much is available when malloc fails on a larger request.  */

 #define SPARE_MEMORY (1 << 14)
-#endif
-
-#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.  */

@@ -3289,9 +3282,9 @@
 {
   /* Do not go into hysterics merely because a large request failed.  */
   int enough_free_memory = 0;
-  if (LARGE_REQUEST < nbytes)
+  if (SPARE_MEMORY < nbytes)
     {
-      void *p = malloc (LARGE_REQUEST);
+      void *p = malloc (SPARE_MEMORY);
       if (p)
 	{
 	  free (p);





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 05 Jul 2011 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 12 years and 324 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.