* Compilation error caused by SPARE_MEMORY
@ 2011-06-05 21:10 Ben Key
2011-06-05 21:54 ` Glenn Morris
2011-06-06 2:50 ` Eli Zaretskii
0 siblings, 2 replies; 7+ messages in thread
From: Ben Key @ 2011-06-05 21:10 UTC (permalink / raw)
To: Emacs Development
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Compilation error caused by SPARE_MEMORY
2011-06-05 21:10 Compilation error caused by SPARE_MEMORY Ben Key
@ 2011-06-05 21:54 ` Glenn Morris
2011-06-06 4:59 ` bug#8800: " Paul Eggert
2011-06-06 4:59 ` Paul Eggert
2011-06-06 2:50 ` Eli Zaretskii
1 sibling, 2 replies; 7+ messages in thread
From: Glenn Morris @ 2011-06-05 21:54 UTC (permalink / raw)
To: Emacs Development
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#8800: Compilation error caused by SPARE_MEMORY
2011-06-05 21:54 ` Glenn Morris
@ 2011-06-06 4:59 ` Paul Eggert
2011-06-06 4:59 ` Paul Eggert
1 sibling, 0 replies; 7+ messages in thread
From: Paul Eggert @ 2011-06-06 4:59 UTC (permalink / raw)
To: Glenn Morris; +Cc: 8800-done, Emacs Development
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;
}
}
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Compilation error caused by SPARE_MEMORY
2011-06-05 21:54 ` Glenn Morris
2011-06-06 4:59 ` bug#8800: " Paul Eggert
@ 2011-06-06 4:59 ` Paul Eggert
2011-06-06 12:02 ` Donald Ephraim Curtis
1 sibling, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2011-06-06 4:59 UTC (permalink / raw)
To: Glenn Morris; +Cc: 8800-done, Emacs Development
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;
}
}
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Compilation error caused by SPARE_MEMORY
2011-06-06 4:59 ` Paul Eggert
@ 2011-06-06 12:02 ` Donald Ephraim Curtis
2011-06-06 16:42 ` bug#8800: " Paul Eggert
0 siblings, 1 reply; 7+ messages in thread
From: Donald Ephraim Curtis @ 2011-06-06 12:02 UTC (permalink / raw)
To: Paul Eggert; +Cc: 8800-done, Emacs Development
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;
> }
> }
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#8800: Compilation error caused by SPARE_MEMORY
2011-06-06 12:02 ` Donald Ephraim Curtis
@ 2011-06-06 16:42 ` Paul Eggert
0 siblings, 0 replies; 7+ messages in thread
From: Paul Eggert @ 2011-06-06 16:42 UTC (permalink / raw)
To: Donald Ephraim Curtis; +Cc: 8800, Emacs Development
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);
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Compilation error caused by SPARE_MEMORY
2011-06-05 21:10 Compilation error caused by SPARE_MEMORY Ben Key
2011-06-05 21:54 ` Glenn Morris
@ 2011-06-06 2:50 ` Eli Zaretskii
1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2011-06-06 2:50 UTC (permalink / raw)
To: Ben Key; +Cc: Emacs-devel
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-06-06 16:42 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-05 21:10 Compilation error caused by SPARE_MEMORY Ben Key
2011-06-05 21:54 ` Glenn Morris
2011-06-06 4:59 ` bug#8800: " Paul Eggert
2011-06-06 4:59 ` Paul Eggert
2011-06-06 12:02 ` Donald Ephraim Curtis
2011-06-06 16:42 ` bug#8800: " Paul Eggert
2011-06-06 2:50 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.