Re: Bug in make-3.81: variable_buffer moves out from under buffer

2009-01-20 Thread David Wuertele 
Martin Dorey  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

2009-01-20 Thread David Wuertele 
Martin Dorey  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

Bug in make-3.81: variable_buffer moves out from under buffer

2009-01-20 Thread David Wuertele 
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