[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recursive invocation of variable_expand_string bug version 3.80

From: Jon Haswell
Subject: Re: Recursive invocation of variable_expand_string bug version 3.80
Date: Thu, 1 Apr 2004 13:38:26 -0800

Thanks for getting back to me so fast. Just after sending the last email I
found the 3.81beta which I assume has the patch included - at least it does
not exhibit the problem.

Jon Haswell
IBM Research
Tel 408 927 2074 Tie 457 2074
Fax 408 927 3030 Tie 457 3030

Robert Schiele <address@hidden> on 04/01/2004 12:40:23 PM

To:    Jon Haswell/San Jose/address@hidden
cc:    address@hidden, address@hidden
Subject:    Re: Recursive invocation of variable_expand_string bug version

On Thu, Apr 01, 2004 at 11:49:42AM -0800, Jon Haswell wrote:
> The problem is in the routine variable_expand_string in how it handles
> access to variable_buffer. When the problem occurs it has been called to
> expand the $(eval $(call ... code above and it does this using the
> variable_buffer size of 200. When this routine is called recursively to
> handle expanding the osbasic.d contents the variable_buffer has to be
> expanded as the contents of osbasic.d are over 200 bytes long. This is
> by the call to realloc which moves variable_buffer. However when we
> to the outer invocation of variable_expand_string it still has its local
> variable 'o', used as the next location in variable_buffer to use, set to
> the old location of variable_buffer before it was expanded/moved. This
> leads to some crazy pointer arithmetic and the attempt to allocate some
> very big buffers and hence the error seen.
> The somewhat obvious fix for this problem would be to make the return
> function from variable_buffer_output just an offset into the buffer
> than the absolute pointer into the buffer. However this routine is used
> frequently and at times in other functions arithmetic is performed
> on variable_buffer that this does not appear to be a simple patch and
> one more familiar with this code might be able to suggest a better
> solution.

This is fixed in CVS by putting the buffer pointer on the stack when
the eval function.  Either get the fix from there, or drop me a note, then
will send you a patch for 3.80.


Robert Schiele                Tel.: +49-621-181-2517
 Dipl.-Wirtsch.informatiker   mailto:address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]