Compilation error caused by SPARE_MEMORY

Compilation error caused by SPARE_MEMORY

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

Hello,

I am seeing a compilation error in alloc.c on line 3287 on Mac OS X due to
SPARE_MEMORY being undeclared.

Starting on line 193 of alloc.c is the following code block that attempts to
define SPARE_MEMORY.

#ifndef SYSTEM_MALLOC
/* Amount of spare memory to keep in large reserve block.  */

#define SPARE_MEMORY (1 << 14)
#endif

The problem is that SYSTEM_MALLOC is defined on Mac OS X but SPARE_MEMORY is
not defined in any of the system header files (at least running 'grep -RnH
SPARE_MEMORY *' in the /usr/include/ directory yields no results).  I
believe that the above code block should be changed to the following but I
am not certain how this change will affect other platforms.

#ifndef SPARE_MEMORY
/* Amount of spare memory to keep in large reserve block.  */

#define SPARE_MEMORY (1 << 14)
#endif

Note that SPARE_MEMORY does not appear to be defined on Windows either.  At
least I could not find it in any of the MinGW header files.

How is SPARE_MEMORY defined on systems that do define it?  Is the above
change the correct one?  It fixes the problem on Mac OS X but I do not want
to make a change that will cause problems for other operating systems.

[-- Attachment #2: Type: text/html, Size: 1512 bytes --]

Re: Compilation error caused by SPARE_MEMORY

[Glenn Morris]

Ben Key wrote:

> I am seeing a compilation error in alloc.c on line 3287 on Mac OS X due to
> SPARE_MEMORY being undeclared.

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

Re: Compilation error caused by SPARE_MEMORY

[Eli Zaretskii]

> From: Ben Key <bkey76@gmail.com>
> Date: Sun, 5 Jun 2011 16:10:30 -0500
> 
> Note that SPARE_MEMORY does not appear to be defined on Windows either.  At
> least I could not find it in any of the MinGW header files.

The Windows build does not suffer from this issue because it does not
define SYSTEM_MALLOC, so SPARE_MEMORY does get defined for Windows.

bug#8800: Compilation error caused by SPARE_MEMORY

[Paul Eggert]

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@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@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;
 	}
     }

Re: Compilation error caused by SPARE_MEMORY

[Paul Eggert]

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@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@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;
 	}
     }

Re: Compilation error caused by SPARE_MEMORY

[Donald Ephraim Curtis]

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@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@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;
> 	}
>     }
> 
> 

bug#8800: Compilation error caused by SPARE_MEMORY

[Paul Eggert]

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