Using alloca in function parameters buggy or works ???

Using alloca in function parameters buggy or works ???

[Kaveh R. Ghazi]

I'm looking over some memory leaks in gcc and I'm seeing lots of funny
uses of concat like this from gcc.c:is_directory()

    strcmp (path,
            concat (dir_separator_str, "lib", dir_separator_str, ".", NULL))

It's pretty clear this memory allocation never gets free'd.  I'd like
to replace stuff like this with ACONCAT from libiberty which uses
alloca and thus doesn't leak.

Normally people don't like alloca I assume because if the backup
libiberty C_alloca is used (which uses malloc underneath the hood),
sometimes stuff isn't free'd because we don't call alloca(0) anywhere.
Then memory use balloons in some edge cases.

However we're already leaking here so if it was a "balloon" case we'd
already know about it. :-)

I'd like to make as little code change as possible for these cases,
which means putting the ACONCAT use (and thus a call to alloca) right
in there as a function call parameter.

My question is that I seem to recall passing the result of alloca
immediately as a function parameter was buggy at some point in GCC.
Using such a version might trigger a bootstrap failure if that buggy
GCC is used in stage1.

So I'm wondering:

1.  Was this bug in any released version of GCC that we care about?
2.  Does my example above trigger the bug?
3.  Any simple workaround?  (Other than don't do that.)

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Using alloca in function parameters buggy or works ???

[Jeffrey A Law]

On Thu, 2004-09-16 at 09:16, Kaveh R. Ghazi wrote:
> I'm looking over some memory leaks in gcc and I'm seeing lots of funny
> uses of concat like this from gcc.c:is_directory()
> 
>     strcmp (path,
>             concat (dir_separator_str, "lib", dir_separator_str, ".", NULL))
> 
> It's pretty clear this memory allocation never gets free'd.  I'd like
> to replace stuff like this with ACONCAT from libiberty which uses
> alloca and thus doesn't leak.
> 
> Normally people don't like alloca I assume because if the backup
> libiberty C_alloca is used (which uses malloc underneath the hood),
> sometimes stuff isn't free'd because we don't call alloca(0) anywhere.
> Then memory use balloons in some edge cases.
> 
> However we're already leaking here so if it was a "balloon" case we'd
> already know about it. :-)
> 
> I'd like to make as little code change as possible for these cases,
> which means putting the ACONCAT use (and thus a call to alloca) right
> in there as a function call parameter.
> 
> My question is that I seem to recall passing the result of alloca
> immediately as a function parameter was buggy at some point in GCC.
> Using such a version might trigger a bootstrap failure if that buggy
> GCC is used in stage1.
> 
> So I'm wondering:
> 
> 1.  Was this bug in any released version of GCC that we care about?
I believe it was in 2.95 and probably everything leading up to
2.95 as well.

> 2.  Does my example above trigger the bug?
Unfortunately, I don't recall all the parameters needed to trigger
the bug, nor do I recall if it was something that was ultimately
unfixable or not.

jeff



jeff

Re: Using alloca in function parameters buggy or works ???

[Graham Stott]

All,

 --- Jeffrey A Law <law@redhat.com> wrote: 
>
[snip]
> > 2.  Does my example above trigger the bug?
> Unfortunately, I don't recall all the parameters needed to trigger
> the bug, nor do I recall if it was something that was ultimately
> unfixable or not.
> 
> jeff
> 

I seem to recall it wasn't only a problem with GCC but other bootstrap
compilers. I have a faint recollection that the original docs for alloca
said something about restrictions on use and func arguments was one of
them, could be wrong.

I do know there was some discussion on the mailing lists at some point
about valid uses of alloca.

Graham

RE: Using alloca in function parameters buggy or works ???

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Kaveh R. Ghazi
> Sent: 16 September 2004 16:16

> I'm looking over some memory leaks in gcc and I'm seeing lots of funny
> uses of concat like this from gcc.c:is_directory()
> 
>     strcmp (path,
>             concat (dir_separator_str, "lib", 
> dir_separator_str, ".", NULL))
> 
> It's pretty clear this memory allocation never gets free'd.  


  Death to the "Why should I bother tracking or freeing resources I've
allocated when the OS will do it for me at process termination" school of
programming!


  If anyone is ever again stupid enough to claim "Oh, but it doesn't really
matter", point them at the graphs showing gcc compile-time memory usage
against successive versions, then point them at all the long and agonised
discussions about it in the archive, then ask them if they'd like to be hit
over the head a thousand times with a matchstick or just once with a tree.

  Then hit them over the head a couple of times with a volume of Knuth and
tell them to go away and google 'scalability'.

;)

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Using alloca in function parameters buggy or works ???

[Robert Dewar]

Dave Korn wrote:

>   Death to the "Why should I bother tracking or freeing resources I've
> allocated when the OS will do it for me at process termination" school of
> programming!

Well I am not so sure this is the right attitude. It may be more valuable
to sign up for the "let's make sure we don't use too many resources"
school of programming. I personally think that problems of excessive
memory use are often better addressed by drastically reducing memory
use in the first place.

It's interesting that in the case of the GNAT front end (which has provision
for freeing stuff, but we have never used it), the only complaints
we have got about excessive memory usage are cases of clearly poor
implementation strategies (really bugs :-)

Re: Using alloca in function parameters buggy or works ???

[Marc Espie]

In article <4149BFCE.3010609@gnat.com> you write:
>Well I am not so sure this is the right attitude. It may be more valuable
>to sign up for the "let's make sure we don't use too many resources"
>school of programming. I personally think that problems of excessive
>memory use are often better addressed by drastically reducing memory
>use in the first place.


Personally, I tend to think `let make it clear what is temporary and
what is more permanent storage'. This is not always clear, but knowing
that storage is local to a function and should not escape in the wild,
or, for instance, having a very clear return path for a function that
does allocate and return memory does help quite a bit.

In my mind, smart gc algorithms take over when this is unclear.

But come on, local algorithms can be written in a clear way... and
alloca stuff won't help all that much.  If it's alloca, then it's
totally local storage, and then temps are just as clear.

Also, this helps in case of code audits: when hunting for memory leaks,
knowing the state of a function wrt to memory allocation does help quite
a lot.

Kaveh's message prompted me in having a closer look at gcc 2.9's use of
concat. Simply put, it's a mess. It's not at all clear which ones are
local and should go. And it's not at all clear what the life extent of
non-local ones are, and if memory can be easily regained, since one has
to find the uses of the function that uses concat, and not just the uses
of concat itself.

Re: Using alloca in function parameters buggy or works ???

[Andreas Schwab]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> 2.  Does my example above trigger the bug?

I think the problem was that alloca'ing the memory could get mixed
together with parameter passing (when they are passed on stack).  So it
probably depends on the order the parameters are set up and whether the
alloca'd memory is the first parameter pushed on stack.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Using alloca in function parameters buggy or works ???

[Jeffrey A Law]

On Thu, 2004-09-16 at 09:58, Andreas Schwab wrote:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> 
> > 2.  Does my example above trigger the bug?
> 
> I think the problem was that alloca'ing the memory could get mixed
> together with parameter passing (when they are passed on stack).  So it
> probably depends on the order the parameters are set up and whether the
> alloca'd memory is the first parameter pushed on stack.
It also probably depends on the types of the other parameters
(consider parameters which must be constructed on the stack).

jeff

RE: Using alloca in function parameters buggy or works ???

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Jeffrey A Law
> Sent: 16 September 2004 17:08

> On Thu, 2004-09-16 at 09:58, Andreas Schwab wrote:
> > "Kaveh R. Ghazi" writes:
> > 
> > > 2.  Does my example above trigger the bug?
> > 
> > I think the problem was that alloca'ing the memory could get mixed
> > together with parameter passing (when they are passed on 
> stack).  So it
> > probably depends on the order the parameters are set up and 
> whether the
> > alloca'd memory is the first parameter pushed on stack.
> It also probably depends on the types of the other parameters
> (consider parameters which must be constructed on the stack).
> 
> jeff



  And how about calling alloca in a varargs function that has an eliminated
frame pointer and incoming args space?  That could be a good way to expose
latent bugs...... <g>


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Using alloca in function parameters buggy or works ???

[Graham Stott]

>   And how about calling alloca in a varargs function that has an eliminated
> frame pointer and incoming args space?  That could be a good way to expose
> latent bugs...... <g>
> 
The backends usually say the frame_pointer is needed if alloca is used.

Graham  

RE: Using alloca in function parameters buggy or works ???

[Dave Korn]

> -----Original Message-----
> From: Graham Stott  
> Sent: 16 September 2004 17:36

> >   And how about calling alloca in a varargs function that 
> has an eliminated
> > frame pointer and incoming args space?  That could be a 
> good way to expose
> > latent bugs...... <g>
> > 
> The backends usually say the frame_pointer is needed if 
> alloca is used.
> 
> Graham  

> -----Original Message-----
> From: Andreas Schwab
> Sent: 16 September 2004 17:39

> "Dave Korn" writes:
> 
> >   And how about calling alloca in a varargs function that 
> has an eliminated
> > frame pointer and incoming args space?  That could be a 
> good way to expose
> > latent bugs...... <g>
> 
> Use of alloca should force a frame pointer.  I don't think 
> that GCC got that ever wrong.


  Well, like I say, combining alloca and varargs ought to make a good
testcase!


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Using alloca in function parameters buggy or works ???

[Andreas Schwab]

"Dave Korn" <dk@artimi.com> writes:

>   And how about calling alloca in a varargs function that has an eliminated
> frame pointer and incoming args space?  That could be a good way to expose
> latent bugs...... <g>

Use of alloca should force a frame pointer.  I don't think that GCC got
that ever wrong.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Using alloca in function parameters buggy or works ???

[DJ Delorie]

Why not just save the pointer to a temporary, and free it after the
strcmp?

Re: Using alloca in function parameters buggy or works ???

[Kaveh R. Ghazi]

 > Why not just save the pointer to a temporary, and free it after the
 > strcmp?

There's a bunch of these cases and I was hoping to perturb the code as
little as possible.

Now that it's been made clear that 2.95 has the bug, I think using a
temporary is the only workable option.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu