Re: Bug in make-3.81: variable_buffer moves out from under buffer
On Tue, 2009-01-20 at 18:53 +, David Wuertele wrote: I posted this to the developer list but got no response. Looks like there's been no activity on that list since October. Is it dead? Anyway, here's the bug report: Which list do you mean by the developer list? It's helpful if you find a bug to report it via Savannah: https://savannah.gnu.org/projects/make/ The code you refer to has been changed in CVS but it looks like this bug is still there. I also have some changes locally to gain memory efficiency which might or might not impact it. Thanks for the report! ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Bug in make-3.81: variable_buffer moves out from under buffer
it looks like this bug is still there
And it looks like there are several other instances of it too.
What I am looking for is some help writing a makefile that
is simple enough to post in a bug report.
I had a few goes but it looks like the variable_buffer is always already
big enough by the time it gets here. Can you tell us what rule it falls
over on for you or what trickery might be associated with that rule? Is
there, for example, re-reading of makefiles going on, or $(eval) magic?
-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Paul
Smith
Sent: Tuesday, January 20, 2009 11:16
To: David Wuertele
Cc: bug-make@gnu.org
Subject: Re: Bug in make-3.81: variable_buffer moves out from under
buffer
On Tue, 2009-01-20 at 18:53 +, David Wuertele wrote:
I posted this to the developer list but got no response. Looks like
there's
been no activity on that list since October. Is it dead? Anyway,
here's the
bug report:
Which list do you mean by the developer list? It's helpful if you find
a bug to report it via Savannah: https://savannah.gnu.org/projects/make/
The code you refer to has been changed in CVS but it looks like this bug
is still there. I also have some changes locally to gain memory
efficiency which might or might not impact it.
Thanks for the report!
-Original Message-
From: bug-make-bounces+mdorey=bluearc@gnu.org
[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of David
Wuertele
Sent: Tuesday, January 20, 2009 10:53
To: bug-make@gnu.org
Subject: Bug in make-3.81: variable_buffer moves out from under buffer
I posted this to the developer list but got no response. Looks like
there's
been no activity on that list since October. Is it dead? Anyway,
here's the
bug report:
I have a very convoluted makefile that triggers what I believe to be a
bug in
make-3.81. I have looked through the savannah buglist and did not find
anything
that resembles it. What I am looking for is some help writing a
makefile that
is simple enough to post in a bug report.
The problem is in expand_deps() in file.c, line 545:
char *o = patsubst_expand (buffer, d-stem, pattern,
dp-name, pattern+1,
percent+1);
if (o == buffer)
dp-name[0] = '\0';
else
{
free (dp-name);
dp-name = savestring (buffer, o - buffer);
}
In the above, the patsubst_expand function calls
variable_buffer_output() with
buffer as the head of the string to write to. But if
variable_buffer_length is
not long enough to hold what patsubst_expand wants to write,
variable_buffer_output() will xrealloc() buffer to a different size,
which could
result in the original contents of buffer getting moved to a different
address.
In this rare case (that I am unable to trigger except in my unpostably
convoluted makefile), the expand_deps() code I quoted above calls
savestring()
on the original value of buffer, which is an address that got freed when
xrealloc moved its original contents. Thus, garbage gets saved in
dp-name.
I have fixed this bug with the following patch. Comments?
Dave
--- make-3.81/file.c~ 2006-03-17 06:24:20.0 -0800
+++ make-3.81/file.c2009-01-16 13:40:30.0 -0800
@@ -545,6 +545,9 @@
char *o = patsubst_expand (buffer, d-stem,
pattern,
dp-name, pattern+1,
percent+1);
+
+ buffer = variable_buffer;
+
if (o == buffer)
dp-name[0] = '\0';
else
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug in make-3.81: variable_buffer moves out from under buffer
Martin Dorey mdorey at bluearc.com writes: And it looks like there are several other instances of it too. That's what I was afraid of. I looked at the other places where xrealloc could get called, but I couldn't find any that referenced the original buffer address after the xrealloc. I suspected that I might have missed some --- xrealloc is used really heavily. What I am looking for is some help writing a makefile that is simple enough to post in a bug report. I had a few goes but it looks like the variable_buffer is always already big enough by the time it gets here. Can you tell us what rule it falls over on for you or what trickery might be associated with that rule? Is there, for example, re-reading of makefiles going on, or $(eval) magic? It is a static pattern rule, during the following function: main() - snap_deps() - expand_deps() This function calls patsubst_expand() on the rule target, and when patsubst_expand returns, the original buffer contents have moved. I tried reducing my makefile to just the two rules that trigger the bug (one that sets variable_buffer to the default size of 200, and one that busts beyond it), but somehow I can't get the variable_buffer to stay at 200 before it gets to the static pattern rule. Here's what I expected the reduced makefile to look like: a1: a%: b%; @echo trash a\ 22: a2%: c%; @echo trash But somehow the variable_buffer is already big enough when it gets to the long rule. Dave ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Bug in make-3.81: variable_buffer moves out from under buffer
In the original makefile, does the long rule really not contain any variables or involve any $(eval) trickery? -Original Message- From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of David Wuertele Sent: Tuesday, January 20, 2009 13:44 To: bug-make@gnu.org Subject: Re: Bug in make-3.81: variable_buffer moves out from under buffer Martin Dorey mdorey at bluearc.com writes: And it looks like there are several other instances of it too. That's what I was afraid of. I looked at the other places where xrealloc could get called, but I couldn't find any that referenced the original buffer address after the xrealloc. I suspected that I might have missed some --- xrealloc is used really heavily. What I am looking for is some help writing a makefile that is simple enough to post in a bug report. I had a few goes but it looks like the variable_buffer is always already big enough by the time it gets here. Can you tell us what rule it falls over on for you or what trickery might be associated with that rule? Is there, for example, re-reading of makefiles going on, or $(eval) magic? It is a static pattern rule, during the following function: main() - snap_deps() - expand_deps() This function calls patsubst_expand() on the rule target, and when patsubst_expand returns, the original buffer contents have moved. I tried reducing my makefile to just the two rules that trigger the bug (one that sets variable_buffer to the default size of 200, and one that busts beyond it), but somehow I can't get the variable_buffer to stay at 200 before it gets to the static pattern rule. Here's what I expected the reduced makefile to look like: a1: a%: b%; @echo trash a222 2\ 22: a2%: c%; @echo trash But somehow the variable_buffer is already big enough when it gets to the long rule. Dave ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug in make-3.81: variable_buffer moves out from under buffer
Martin Dorey mdorey at bluearc.com writes: In the original makefile, does the long rule really not contain any variables or involve any $(eval) trickery? Not sure what you mean by trickery, but it definitely involves eval and variables. The rule is created with an eval: $(eval $(call somemacro,many,different,arguments,many,many,many)) somemacro calls other macros: define somemacro $(foreach thing,$(filter-out unwanted-stuff,$(wildcard $1/*)),$(call othermacro,$1,$(thing),$2,$3,and,more,stuff)) endef othermacro calls yet more functions: define othermacro $(patsubst $1/%.x,$3/.y-%,$2): $3/.y-%: $1/%.x; echo blah blah blah endef When I unwind these calls and write the expansion out manually, I invariably change the order that stuff gets evaluated, which results in variable_buffer being large enough to avoid triggering the bug. Dave ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Bug in make-3.81: variable_buffer moves out from under buffer
Thanks. I was hoping it'd be something like that. Even with that clue, though, I'm not having any luck making the buffer need reallocating at the appropriate point. How frustrating. -Original Message- From: bug-make-bounces+mdorey=bluearc@gnu.org [mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of David Wuertele Sent: Tuesday, January 20, 2009 15:07 To: bug-make@gnu.org Subject: Re: Bug in make-3.81: variable_buffer moves out from under buffer Martin Dorey mdorey at bluearc.com writes: In the original makefile, does the long rule really not contain any variables or involve any $(eval) trickery? Not sure what you mean by trickery, but it definitely involves eval and variables. The rule is created with an eval: $(eval $(call somemacro,many,different,arguments,many,many,many)) somemacro calls other macros: define somemacro $(foreach thing,$(filter-out unwanted-stuff,$(wildcard $1/*)),$(call othermacro,$1,$(thing),$2,$3,and,more,stuff)) endef othermacro calls yet more functions: define othermacro $(patsubst $1/%.x,$3/.y-%,$2): $3/.y-%: $1/%.x; echo blah blah blah endef When I unwind these calls and write the expansion out manually, I invariably change the order that stuff gets evaluated, which results in variable_buffer being large enough to avoid triggering the bug. Dave ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
