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

[Martin Dorey]

> 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: address@hidden
[mailto:address@hidden On Behalf Of Paul
Smith
Sent: Tuesday, January 20, 2009 11:16
To: David Wuertele
Cc: address@hidden
Subject: Re: Bug in make-3.81: variable_buffer moves out from under
buffer

On Tue, 2009-01-20 at 18:53 +0000, 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: address@hidden
[mailto:address@hidden On Behalf Of David
Wuertele
Sent: Tuesday, January 20, 2009 10:53
To: address@hidden
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.000000000 -0800
+++ make-3.81/file.c    2009-01-16 13:40:30.000000000 -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