GDB GNATS bug tracking database available

GDB GNATS bug tracking database available

[Christopher Faylor]

I've set up a GNATS database for entering GDB bugs.  The easiest way
to find it is to go to the gdb web page and follow the BUGS link.

http://sources.redhat.com/gdb/

There is also an associated gdb-prs mailing list.  You can subscribe to
it by sending email to:

gdb-prs-subscribe@sources.redhat.com

I've given "edit" privileges to every name and email address that is
currently in the MAINTAINERS file as well as everyone else that I knew
was working on gdb.

If I missed somebody, let me know.

cgf

Re: GDB GNATS bug tracking database available

[Kevin Buettner]

On Oct 26, 11:10pm, Christopher Faylor wrote:

> I've set up a GNATS database for entering GDB bugs.  The easiest way
> to find it is to go to the gdb web page and follow the BUGS link.
> 
> http://sources.redhat.com/gdb/

I'm playing around with it now and I'm able to query all of the
bugs, but when I try to view one of them by clicking on the bug's
number, I see:

View Problem Report: 12   User: guest
Database: gdb
Access: viewconf
Error: no PRs matched

Is this right?

Re: GDB GNATS bug tracking database available

[Fernando Nasser]

Kevin Buettner wrote:
> 
> On Oct 26, 11:10pm, Christopher Faylor wrote:
> 
> > I've set up a GNATS database for entering GDB bugs.  The easiest way
> > to find it is to go to the gdb web page and follow the BUGS link.
> >
> > http://sources.redhat.com/gdb/
> 
> I'm playing around with it now and I'm able to query all of the
> bugs, but when I try to view one of them by clicking on the bug's
> number, I see:
> 
> View Problem Report: 12   User: guest
> Database: gdb
> Access: viewconf
> Error: no PRs matched
> 
> Is this right?

No, you have to login first.  There is an option in the query page
that says "login again".  Use that first and you'll get edit priviledges.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: GDB GNATS bug tracking database available

[Christopher Faylor]

On Thu, Oct 26, 2000 at 09:18:02PM -0700, Kevin Buettner wrote:
>On Oct 26, 11:10pm, Christopher Faylor wrote:
>
>> I've set up a GNATS database for entering GDB bugs.  The easiest way
>> to find it is to go to the gdb web page and follow the BUGS link.
>> 
>> http://sources.redhat.com/gdb/
>
>I'm playing around with it now and I'm able to query all of the
>bugs, but when I try to view one of them by clicking on the bug's
>number, I see:
>
>View Problem Report: 12   User: guest
>Database: gdb
>Access: viewconf
>Error: no PRs matched
>
>Is this right?

I had deleted all of my testing PRs and forgot to delete the
accompanying index entries, so, yes, this is correct.

I've zeroed the index and added one PR.  After waiting for the normal
ten minute lag between entering a PR and seeing it show up via gnatsweb,
it seems to be viewable using the normal method.  I.e., you don't have to
login.

Apologies for the confusion.

cgf

Re: GDB GNATS bug tracking database available

[Andrew Cagney]

Chris, thanks!  This leaves us with just one non-programming issue (test
results page) for 5.1.  There are still plenty of programming (TODO)
issues to resolve though.

	Andrew

Subscribe gdb-prs@sources.redhat.com to gdb@sources.redhat.com?

[Christopher Faylor]

Does anyone have any objections to subscribing the gdb-prs mailing list
to this mailing list?  I thought that, theoretically, any problems that
show up in the gdb-prs database would be of interest here.

cgf

Re: Subscribe gdb-prs@sources.redhat.com to gdb@sources.redhat.com?

[Andrew Cagney]

Christopher Faylor wrote:
> 
> Does anyone have any objections to subscribing the gdb-prs mailing list
> to this mailing list?  I thought that, theoretically, any problems that
> show up in the gdb-prs database would be of interest here.

Would it defeat the purpose of a separate gdb-prs mailing list?  Er,
actually I'm not sure.  Can you expand a little on what would end up
where, where it would appear to come from, and what would happen if I
did a reply all?

	Andrew

Re: Subscribe gdb-prs@sources.redhat.com to gdb@sources.redhat.com?

[Christopher Faylor]

On Wed, Nov 01, 2000 at 04:22:48PM +1100, Andrew Cagney wrote:
>Christopher Faylor wrote:
>>Does anyone have any objections to subscribing the gdb-prs mailing list
>>to this mailing list?  I thought that, theoretically, any problems that
>>show up in the gdb-prs database would be of interest here.
>
>Would it defeat the purpose of a separate gdb-prs mailing list?  Er,
>actually I'm not sure.  Can you expand a little on what would end up
>where, where it would appear to come from, and what would happen if I
>did a reply all?

This type of thing would show up in the mailing list:

>From: ajagarao@hotmail.com
>To: gdb-gnats@sources.redhat.com
>Subject: gdb/2: i am unable to download gdb free debugger into my AIX system
>Date: 31 Oct 2000 18:08:31 -0000
>Resent-To: nobody@sources.redhat.com
>Resent-Cc: gdb-prs@sources.redhat.com
>Resent-Reply-To: gdb-gnats@sources.redhat.com, ajagarao@hotmail.com
>Reply-To: ajagarao@hotmail.com
>
>
>>Number:         2
>>Category:       gdb
>>Synopsis:       i am unable to download gdb free debugger into my AIX system
>>Confidential:   no
>>Severity:       serious
>>Priority:       medium
>>Responsible:    unassigned
>>State:          open
>>Class:          sw-bug
>>Submitter-Id:   net
>>Arrival-Date:   Tue Oct 31 10:18:00 PST 2000
>>Closed-Date:
>>Last-Modified:
>>Originator:     Jaga
>>Release:        unknown-1.0
>>Organization:
>>Environment:
>AIX
>>Description:
>
>>How-To-Repeat:
>
>>Fix:
>
>>Release-Note:
>>Audit-Trail:

I believe that replies would end up in the PR but I don't know for sure.
I don't have any experience with GNATS, unfortunately.  I just set it up
using a torturous cookbook process.

Maybe someone with more experience with GNATS can answer more definitively.

cgf

Re: Subscribe gdb-prs@sources.redhat.com to gdb@sources.redhat.com?

[Kevin Buettner]

On Nov 1, 12:33am, Christopher Faylor wrote:

> On Wed, Nov 01, 2000 at 04:22:48PM +1100, Andrew Cagney wrote:
> >Christopher Faylor wrote:
> >>Does anyone have any objections to subscribing the gdb-prs mailing list
> >>to this mailing list?  I thought that, theoretically, any problems that
> >>show up in the gdb-prs database would be of interest here.
> >
> >Would it defeat the purpose of a separate gdb-prs mailing list?  Er,
> >actually I'm not sure.  Can you expand a little on what would end up
> >where, where it would appear to come from, and what would happen if I
> >did a reply all?
> 
> I believe that replies would end up in the PR but I don't know for sure.
> I don't have any experience with GNATS, unfortunately.  I just set it up
> using a torturous cookbook process.

What about auto-subscribing each member of the list individually?

That way we have a way to opt out if we want to.

Kevin

Re: Subscribe gdb-prs@sources.redhat.com to gdb@sources.redhat.com?

[Tom Tromey]

Chris> I believe that replies would end up in the PR but I don't know
Chris> for sure.

Ordinarily you have to CC the `-gnats' address to get the message in
the PR.  Unfortunately sometimes Gnats sends out a message to (eg)
gdb-prs@... and then if you reply to all you don't CC gdb-gnats.

Tom

Re: Subscribe gdb-prs@sources.redhat.com to gdb@sources.redhat.com?

[Christopher Faylor]

On Wed, Nov 01, 2000 at 10:15:48AM -0700, Tom Tromey wrote:
>Chris> I believe that replies would end up in the PR but I don't know
>Chris> for sure.
>
>Ordinarily you have to CC the `-gnats' address to get the message in
>the PR.  Unfortunately sometimes Gnats sends out a message to (eg)
>gdb-prs@... and then if you reply to all you don't CC gdb-gnats.

Ok.  I have gotten some negative feedback on this, so I will abandon the
idea unless there is a public outcry for me to do this.

I do encourage everyone to subscribe to gdb-prs, though:

gdb-prs-subscribe@sources.redhat.com

The database now has what looks like an actual bug in it.

cgf

alloca is bad?

[Christopher Faylor]

A patch that I recently submitted to gdb-patches used the alloca ()
function to allocate memory.  I've been told in private email that I
mustn't use alloca because "stack corruption problems are harder to
debug" than heap corruption problems.

I was surprised by this assertion and so I thought I'd ask for a
consensus here.  Should the use of alloca be deprecated in gdb?

It is my assertion that the amount of bookkeeping and overhead required
to use malloc in a way that is analogous with alloca essentially
nullifies the "harder to debug" argument.  malloc requires a free and
many times, in gdb context, the only way to guarantee a free is with the
use of the cleanup function.  Any time you add the complexity of
something like 'cleanup()' (or whatever other mechanism you use to
ensure that what you malloc is automatically freed) you can't claim to
have reduced debugging problems.  Speaking of free, with alloca you
don't have memory leaks.  With malloc, you do.

If alloca is bad, then why are local arrays and pointers to local
variables and parameters ok?

Inquiring minds...

cgf

Re: alloca is bad?

[Michael Meissner]

On Thu, Nov 09, 2000 at 09:20:32PM -0500, Christopher Faylor wrote:
> A patch that I recently submitted to gdb-patches used the alloca ()
> function to allocate memory.  I've been told in private email that I
> mustn't use alloca because "stack corruption problems are harder to
> debug" than heap corruption problems.
> 
> I was surprised by this assertion and so I thought I'd ask for a
> consensus here.  Should the use of alloca be deprecated in gdb?
> 
> It is my assertion that the amount of bookkeeping and overhead required
> to use malloc in a way that is analogous with alloca essentially
> nullifies the "harder to debug" argument.  malloc requires a free and
> many times, in gdb context, the only way to guarantee a free is with the
> use of the cleanup function.  Any time you add the complexity of
> something like 'cleanup()' (or whatever other mechanism you use to
> ensure that what you malloc is automatically freed) you can't claim to
> have reduced debugging problems.  Speaking of free, with alloca you
> don't have memory leaks.  With malloc, you do.
> 
> If alloca is bad, then why are local arrays and pointers to local
> variables and parameters ok?
> 
> Inquiring minds...

It depends on many things.  For any allocation that might involve a large
number of items (say more than a page worth), it is better to use malloc than
alloca.  This is due to a couple of factors:

   1)	Stack space is usually more limited than data space.  On some systems
	(ie, Windows), this is set at link time, while on others it can be set
	by the parent shell (though usually the parent can't set the limit
	higher than it's limit).  By the way, this affects large auto arrays
	with static bounds as well.

   2)	There is no error return value for alloca, so you can't have a more
	friendly exit, instead the heap just gets corrupted.  The compiler just
	allocates extra memory and assumes the stack is big enough.

   3)	Large allocations of more than a page might confuse the OS's method of
	growing the stack, which expects to be done via a function prologue.

   4)	There are 3rd party tools to check for pointers being out of bounds for
	malloc requests like electric fence that you can plug in to get the
	checking.

The FSF GCC maintainers have gone through and tried to eliminate all allocas of
any based off of the number of pseudo registers, basic blocks, or other
variable things, and certainly seems to reduce the number of people complaining
that their Windows compiler just died without warning.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: alloca is bad?

[Christopher Faylor]

On Thu, Nov 09, 2000 at 09:37:50PM -0500, Michael Meissner wrote:
>On Thu, Nov 09, 2000 at 09:20:32PM -0500, Christopher Faylor wrote:
>>A patch that I recently submitted to gdb-patches used the alloca ()
>>function to allocate memory.  I've been told in private email that I
>>mustn't use alloca because "stack corruption problems are harder to
>>debug" than heap corruption problems.
>>
>>I was surprised by this assertion and so I thought I'd ask for a
>>consensus here.  Should the use of alloca be deprecated in gdb?
>>
>>It is my assertion that the amount of bookkeeping and overhead required
>>to use malloc in a way that is analogous with alloca essentially
>>nullifies the "harder to debug" argument.  malloc requires a free and
>>many times, in gdb context, the only way to guarantee a free is with
>>the use of the cleanup function.  Any time you add the complexity of
>>something like 'cleanup()' (or whatever other mechanism you use to
>>ensure that what you malloc is automatically freed) you can't claim to
>>have reduced debugging problems.  Speaking of free, with alloca you
>>don't have memory leaks.  With malloc, you do.
>>
>>If alloca is bad, then why are local arrays and pointers to local
>>variables and parameters ok?
>>
>>Inquiring minds...
>
>It depends on many things.  For any allocation that might involve a large
>number of items (say more than a page worth), it is better to use malloc than
>alloca.  This is due to a couple of factors:
>
>   1)	Stack space is usually more limited than data space.  On some systems
>	(ie, Windows), this is set at link time, while on others it can be set
>	by the parent shell (though usually the parent can't set the limit
>	higher than it's limit).  By the way, this affects large auto arrays
>	with static bounds as well.

I should have made the context clearer.  I am not advocating that alloca
replace malloc or that malloc is useless.  I understand (and hopefully
everyon who uses alloca understands) that you should not allocate 16MB
of information using alloca any more than you should have a 16M local
array.

>   2)	There is no error return value for alloca, so you can't have a more
>	friendly exit, instead the heap just gets corrupted.  The compiler just
>	allocates extra memory and assumes the stack is big enough.

This is probably a valid concern but it doesn't mean that you eliminate the
use of alloca.  It means that you use it responsibly.  Again, auto arrays
would suffer from the same problem.

>   3)	Large allocations of more than a page might confuse the OS's method of
>	growing the stack, which expects to be done via a function prologue.

You probably know more about this than I, however I there are something
like 2900 occurrences of the word 'alloca' in gcc.  I see alloca() used
to allocate space for path names and it is used in other places where
the length it is passed is not obviously checked for violation of the
page size.  So, if this is an issue then gcc must not work too well on
these OSes.

>   4)	There are 3rd party tools to check for pointers being out of bounds for
>	malloc requests like electric fence that you can plug in to get the
>	checking.
>
>The FSF GCC maintainers have gone through and tried to eliminate all allocas of
>any based off of the number of pseudo registers, basic blocks, or other
>variable things, and certainly seems to reduce the number of people complaining
>that their Windows compiler just died without warning.

The fact that there are debugging tools like Purify or Electric Fence
doesn't really seem like an argument to me.  To some degree, these tools
exist exactly because of the problems with the malloc/free paradigm.
You don't have memory leaks with alloca so you don't need a special tool
to track down memory leaks.

You can, of course, have array overruns with an alloca'ed buffer just
like you can with a malloced array.  In my experience, tracking down
stack corruption is usually a relatively trivial exercise essentially
involving a binary search.  With heap corruption the problems don't
necessarily manifest in a deterministic way.  A buffer overrun in
function x may cause a problem in function q even though function q is
not part of function x's call tree.  So, problems with heap corruption
are much less bounded.

Hmm.  I think that Purify actually does help track down stack corruption
so there is at least one tool for this.  I've never used Electric Fence
but I would be surprised if it was completely trivial to use and I would
be equally surprised if linking with Electric Fence automatically
pinpointed heap problems in every case.  In my experience with debugging
mallocs, adding them to the equation sometimes changes everything since
the allocation schemes are usually different from the system malloc that
is commonly used when linking applications.  So, using debugging mallocs
can actually mask or alter how the heap problem manifests.

However, even if it was the case that debugging problems with alloca was
more problematic than debugging heap problems, I don't think that this
is a compelling argument for not using alloca.  The added complexity
required to get malloc/free to do what alloca does naturally, coupled
with the added overhead required for managing the heap are two factors
that weigh against using malloc for everything IMO.

And, again, I can't think of any argument against using alloca that
doesn't also apply to automatic arrays.  If we are going to stop
using alloca then we should stop allocating automatic arrays, too.

I am not advocating replacing every malloc in gdb with alloca.  I'm just
lobbying against the "throwing out the baby with the bath water"
approach.  Alloca is useful.  IMO, its use should not be automatically
prohibited in all future gdb submissions.

cgf

Re: alloca is bad?

[Nick Duffek]

On 9-Nov-2000, Christopher Faylor wrote:

>I've been told in private email that I mustn't use alloca

Say it ain't so!

>Alloca is useful.

Especially because multi-arching is turning small compile-time constants
into run-time variables all over the place.  If we can't use alloca, then
wherever there's something like this:

  char rawbuf[MAX_REGISTER_SIZE];

we'll have to convert it to this:

  char *rawbuf;
  ...
  rawbuf = malloc (MAX_REGISTER_SIZE);

and do one of two things:

  1. Perform the usual painful cleanup-chain surgery.

  2. Carefully analyze the function and its entire call subtree to make
     sure non-local returns are impossible.

Either way, we're in for a lot more complexity -- and therefore bugs --
than if we use alloca.

Nick

Re: alloca is bad?

[Andrew Cagney]

Nick Duffek wrote:
> 
> On 9-Nov-2000, Christopher Faylor wrote:
> 
> >I've been told in private email that I mustn't use alloca
> 
> Say it ain't so!
> 
> >Alloca is useful.
> 
> Especially because multi-arching is turning small compile-time constants
> into run-time variables all over the place.  If we can't use alloca, then
> wherever there's something like this:
> 
>   char rawbuf[MAX_REGISTER_SIZE];

This is being converted to

	char *rawbuf = alloca (MAX_REGISTER_SIZE);

with the knowledge that it probably isn't going to work on some hosts. 
The conversion is tolerated because a more significant change incures
greater risk (bigger chance of someone botching it :-).

At the time it was agreed that such alloca() calls should eventually be
eliminated.

	Andrew

Re: alloca is bad?

[Christopher G. Faylor]

On Fri, Nov 10, 2000 at 05:11:55PM +1100, Andrew Cagney wrote:
>Nick Duffek wrote:
>> 
>> On 9-Nov-2000, Christopher Faylor wrote:
>> 
>> >I've been told in private email that I mustn't use alloca
>> 
>> Say it ain't so!
>> 
>> >Alloca is useful.
>> 
>> Especially because multi-arching is turning small compile-time constants
>> into run-time variables all over the place.  If we can't use alloca, then
>> wherever there's something like this:
>> 
>>   char rawbuf[MAX_REGISTER_SIZE];
>
>This is being converted to
>
>	char *rawbuf = alloca (MAX_REGISTER_SIZE);
>
>with the knowledge that it probably isn't going to work on some hosts. 
>The conversion is tolerated because a more significant change incures
>greater risk (bigger chance of someone botching it :-).
>
>At the time it was agreed that such alloca() calls should eventually be
>eliminated.

Why?

cgf

Re: alloca is bad?

[Andrew Cagney]

Christopher Faylor wrote:
> 
> A patch that I recently submitted to gdb-patches used the alloca ()
> function to allocate memory.  I've been told in private email that I
> mustn't use alloca because "stack corruption problems are harder to
> debug" than heap corruption problems.

The principal reason is that it is non-portable. Some hosts have fairly
arbitrary limits on how much can be alloca()'d.  A black/white please
don't use this is easier to follow than some vague ``only when''
guideline .... Yes, multi-arch has put us into the grey.

Other secondary factors in the decision would have included the
observation that alloca (and stack arrays) (well actually just C :-) can
lead to nasy buffer overflow bugs that corrupt the stack.

	Andrew


> I was surprised by this assertion and so I thought I'd ask for a
> consensus here.  Should the use of alloca be deprecated in gdb?
> 
> It is my assertion that the amount of bookkeeping and overhead required
> to use malloc in a way that is analogous with alloca essentially
> nullifies the "harder to debug" argument.  malloc requires a free and
> many times, in gdb context, the only way to guarantee a free is with the
> use of the cleanup function.  Any time you add the complexity of
> something like 'cleanup()' (or whatever other mechanism you use to
> ensure that what you malloc is automatically freed) you can't claim to
> have reduced debugging problems.  Speaking of free, with alloca you
> don't have memory leaks.  With malloc, you do.
> 
> If alloca is bad, then why are local arrays and pointers to local
> variables and parameters ok?
> 
> Inquiring minds...
> 
> cgf

Re: alloca is bad?

[Eli Zaretskii]

> Date: Thu, 9 Nov 2000 21:20:32 -0500
> From: Christopher Faylor <cgf@redhat.com>
> 
> I was surprised by this assertion and so I thought I'd ask for a
> consensus here.  Should the use of alloca be deprecated in gdb?

In my experience, there's nothing wrong with alloca as long as it is
used for allocating small buffers.  The only consideration is that not
every platform supports alloca.

Re: alloca is bad?

[Eli Zaretskii]

> Date: Thu, 9 Nov 2000 22:22:31 -0500
> From: Christopher Faylor <cgf@redhat.com>
> 
> You can, of course, have array overruns with an alloca'ed buffer just
> like you can with a malloced array.

IMHO, buffer overruns are irrelevant to this issue, since they happen
with automatic arrays as well, and are equally hard (or simple) to
track.

> Hmm.  I think that Purify actually does help track down stack corruption
> so there is at least one tool for this.  I've never used Electric Fence
> but I would be surprised if it was completely trivial to use and I would
> be equally surprised if linking with Electric Fence automatically
> pinpointed heap problems in every case.

You are right, as long as my experience goes.  Malloc debuggers are
anything but trivial to use, and some large programs which allocate
memory all the time, such as Emacs, are practically impossible to
debug using these tools, at least those of them which use page
protection to catch buffer overruns.

Re: alloca is bad?

[Jim Blandy]

I think alloca is terribly useful.  I have every intention of using it
the next time it's appropriate.  We should not reject new uses of
alloca.

Of course, strictly typed mechanisms, like GCC's dynamically sized
arrays, are preferable, but not widely available.

Re: alloca is bad?

[Chris Faylor]

On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
>> Date: Thu, 9 Nov 2000 21:20:32 -0500
>> From: Christopher Faylor <cgf@redhat.com>
>> 
>> I was surprised by this assertion and so I thought I'd ask for a
>> consensus here.  Should the use of alloca be deprecated in gdb?
>
>In my experience, there's nothing wrong with alloca as long as it is
>used for allocating small buffers.  The only consideration is that not
>every platform supports alloca.

But, since alloca is already entrenched in gdb and available in liberty
I don't think this is an issue, is it?

cgf

Re: alloca is bad?

[Christopher Faylor]

On Fri, Nov 10, 2000 at 09:21:51AM -0500, Jim Blandy wrote:
>I think alloca is terribly useful.  I have every intention of using it
>the next time it's appropriate.  We should not reject new uses of
>alloca.
>
>Of course, strictly typed mechanisms, like GCC's dynamically sized
>arrays, are preferable, but not widely available.

I agree with this.  I use dynamically sized arrays in cygwin because it
is guaranteed to be compiled by gcc.

Are dynamically sized arrays part of C99 by any chance?

cgf

Re: alloca is bad?

[Fernando Nasser]

Chris Faylor wrote:
> 
> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> >> From: Christopher Faylor <cgf@redhat.com>
> >>
> >> I was surprised by this assertion and so I thought I'd ask for a
> >> consensus here.  Should the use of alloca be deprecated in gdb?
> >
> >In my experience, there's nothing wrong with alloca as long as it is
> >used for allocating small buffers.  The only consideration is that not
> >every platform supports alloca.
> 
> But, since alloca is already entrenched in gdb and available in liberty
> I don't think this is an issue, is it?
> 

Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
our interpreter's command loops or the garbage collection becomes somewhat
random (it will only happen when you call alloca() for allocating some
other stuff and will only clean what was allocated by code that executed on frames
below the current stack position.

I think we have this bug when alloca() gets used right now.

(Nothing difficult, we just need to remember to do it)


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: alloca is bad?

[Christopher Faylor]

On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser wrote:
>Chris Faylor wrote:
>> 
>> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
>> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
>> >> From: Christopher Faylor <cgf@redhat.com>
>> >>
>> >> I was surprised by this assertion and so I thought I'd ask for a
>> >> consensus here.  Should the use of alloca be deprecated in gdb?
>> >
>> >In my experience, there's nothing wrong with alloca as long as it is
>> >used for allocating small buffers.  The only consideration is that not
>> >every platform supports alloca.
>> 
>> But, since alloca is already entrenched in gdb and available in liberty
>> I don't think this is an issue, is it?
>> 
>
>Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
>our interpreter's command loops or the garbage collection becomes somewhat
>random (it will only happen when you call alloca() for allocating some
>other stuff and will only clean what was allocated by code that executed on frames
>below the current stack position.
>
>I think we have this bug when alloca() gets used right now.
>
>(Nothing difficult, we just need to remember to do it)

% fgrep 'alloca (0)' *.c
gnu-regex.c:      alloca (0);
gnu-regex.c:  alloca (0);
gnu-regex.c:  alloca (0);
regcache.c:  alloca (0);
top.c:  alloca (0);

cgf

Re: alloca is bad?

[Michael Meissner]

On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser wrote:
> Chris Faylor wrote:
> > 
> > On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> > >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> > >> From: Christopher Faylor <cgf@redhat.com>
> > >>
> > >> I was surprised by this assertion and so I thought I'd ask for a
> > >> consensus here.  Should the use of alloca be deprecated in gdb?
> > >
> > >In my experience, there's nothing wrong with alloca as long as it is
> > >used for allocating small buffers.  The only consideration is that not
> > >every platform supports alloca.
> > 
> > But, since alloca is already entrenched in gdb and available in liberty
> > I don't think this is an issue, is it?
> > 
> 
> Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
> our interpreter's command loops or the garbage collection becomes somewhat
> random (it will only happen when you call alloca() for allocating some
> other stuff and will only clean what was allocated by code that executed on frames
> below the current stack position.
> 
> I think we have this bug when alloca() gets used right now.
> 
> (Nothing difficult, we just need to remember to do it)

Note, that liberty's alloca will only be used if the host compiler is not GCC,
which probably makes it even harder to remember to use....  BTW, there are
systems out there that even's liberty's alloca will not work on (due to either
using a cactus stack or allocating the stack in pieces from the heap).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: alloca is bad?

[Fernando Nasser]

Christopher Faylor wrote:
> 
> On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser wrote:
> >Chris Faylor wrote:
> >>
> >> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> >> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> >> >> From: Christopher Faylor <cgf@redhat.com>
> >> >>
> >> >> I was surprised by this assertion and so I thought I'd ask for a
> >> >> consensus here.  Should the use of alloca be deprecated in gdb?
> >> >
> >> >In my experience, there's nothing wrong with alloca as long as it is
> >> >used for allocating small buffers.  The only consideration is that not
> >> >every platform supports alloca.
> >>
> >> But, since alloca is already entrenched in gdb and available in liberty
> >> I don't think this is an issue, is it?
> >>
> >
> >Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to
> >our interpreter's command loops or the garbage collection becomes somewhat
> >random (it will only happen when you call alloca() for allocating some
> >other stuff and will only clean what was allocated by code that executed on frames
> >below the current stack position.
> >
> >I think we have this bug when alloca() gets used right now.
> >
> >(Nothing difficult, we just need to remember to do it)
> 
> % fgrep 'alloca (0)' *.c
> gnu-regex.c:      alloca (0);
> gnu-regex.c:  alloca (0);
> gnu-regex.c:  alloca (0);
> regcache.c:  alloca (0);



> top.c:  alloca (0);

That takes care of the CLI commands.  (MI and Insight are probably broken)

Any other interpreter that uses the libgdb exported functions instead
of the CLI execute_command will have to do the same.  How can we control
that this is done if a script, for instance, calls random libgdb functions?

Maybe we will have to add a call to alloca(0) to every libgdb call.

(Or not used the darn thing!)

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: alloca is bad?

[Eli Zaretskii]

> Date: Fri, 10 Nov 2000 11:16:51 -0500
> From: Chris Faylor <cgf@redhat.com>
> >
> >In my experience, there's nothing wrong with alloca as long as it is
> >used for allocating small buffers.  The only consideration is that not
> >every platform supports alloca.
> 
> But, since alloca is already entrenched in gdb and available in liberty
> I don't think this is an issue, is it?

I don't think this should be an issue.

Re: alloca is bad?

[Andrew Cagney]

Chris Faylor wrote:
> 
> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> >> From: Christopher Faylor <cgf@redhat.com>
> >>
> >> I was surprised by this assertion and so I thought I'd ask for a
> >> consensus here.  Should the use of alloca be deprecated in gdb?
> >
> >In my experience, there's nothing wrong with alloca as long as it is
> >used for allocating small buffers.  The only consideration is that not
> >every platform supports alloca.
> 
> But, since alloca is already entrenched in gdb and available in liberty
> I don't think this is an issue, is it?

There are a many entrenched practices in GDB and many of those we don't
want to perpetuate.  Typically, these were either viewed as innocent
short-cuts or simply as good ideas.  In hindsight (we've 15 years worth
now :-) these practices turned out to be somewhat misguided.  Part of
our penance is that on-going maintenance expense we incur when ever we
touch the code.

Consider Peter S's example as a case in point - it looked harmless :-)

	enjoy,
		Andrew

Re: alloca is bad?

[Andrew Cagney]

Jim Blandy wrote:
> 
> I think alloca is terribly useful.  I have every intention of using it
> the next time it's appropriate.  We should not reject new uses of
> alloca.

To decide it is appropriate I think there need to be some clear and
objective guidelines.  Otherwise people submitting code are going to run
into the problem that their submition is being accepted or dismissed
based on the arbitrary wim of the reviewer.  It also means that what
ever decision is reached it has some rationale behind it - otherwize the
alloca debate will just flare up again in another 6 months.

The discussion has already identified the issues:

	o	need to call alloca(0) somewhere
		(perhaphs do_cleanups() should do this :-)

	o	total stack bound of <2mb

	o	(from memory) limit of 64k
		on a single stack frame
		(some rs6000 platforms)

	o	the suggestion that some platforms
		don't support even libiberty's alloca.

		I'd be very interested in knowing the
		details of this.

> Of course, strictly typed mechanisms, like GCC's dynamically sized
> arrays, are preferable, but not widely available.

(Personally, since C doesn't do bounds checking, I think dyamic arrays
are only slightly better :-)

This brings up an additional, possibly relevent, point.  Given the code:

	int a[size];
vs
	int *const a = alloca (size * sizeof (int));
or	int *const a = (int *) alloca (size & sizeof (int));

(er and there is even one in the above and no it wasn't contrived!) the
latter definitely has more potential error points (both when being
written and being maintained).  Coding pratices that minimize a
programmers error rate should be considered.

One ``cute trick'' I'm guilty of is probably worth considering:

	#define XCALLOC(N,TYPE) ((TYPE *) xmalloc ((N) * sizeof (TYPE)))
	int *a = XCALLOC (size, int);

(which works because GDB has a zero tolerance policy towards basic
warnings).

	Andrew

Re: alloca is bad?

[Andrew Cagney]

Fernando Nasser wrote:

> That takes care of the CLI commands.  (MI and Insight are probably broken)
> 
> Any other interpreter that uses the libgdb exported functions instead
> of the CLI execute_command will have to do the same.  How can we control
> that this is done if a script, for instance, calls random libgdb functions?
> 
> Maybe we will have to add a call to alloca(0) to every libgdb call.

I'd argue that the analysis of this error demonstrates that people are
going to forget to call alloca(0).  It is after all an obscure querk of
libiberty and not exactly a normal C convention.

Based on that, inserting an alloca(0) call in every libgdb function
probably is best :-(

	enjoy,
		Andrew

Re: alloca is bad?

[Eli Zaretskii]

> Date: Sat, 11 Nov 2000 17:06:19 +1100
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> 	o	total stack bound of <2mb

The default stack size of DJGPP programs is 512KB.  It is allocated at
startup time in its entirety, and cannot be changed while the program
runs.

If we want to be more defensive against possible stack overflows due
to alloca, we need to use getrlimit.

In any case, we should be able to define some maximum size that is
allowed to be used with alloca, and write it up in the coding
standards.  Then code accept/reject criteria are no longer arbitrary,
they are corporate policy ;-)

Re: alloca is bad?

[Nick Duffek]

On 11-Nov-2000, Andrew Cagney wrote:

>This brings up an additional, possibly relevent, point.  Given the code:

>	int a[size];

>vs
>	int *const a = alloca (size * sizeof (int));
>or	int *const a = (int *) alloca (size & sizeof (int));

>(er and there is even one in the above and no it wasn't contrived!) the
>latter definitely has more potential error points (both when being
>written and being maintained).  Coding pratices that minimize a
>programmers error rate should be considered.

That's one of the strongest arguments in favor of alloca over malloc.  The
programmer error potential in these two lines of code:

	int *const a = alloca (size * sizeof (int));
	int *const a = malloc (size * sizeof (int));

is exactly the same, but adding free() in the malloc case adds much more
potential for errors, as demonstrated by the popularity of tools for
finding memory leaks.  The malloc case gets even more error-prone where we
need to check for non-local exits and add cleanup chains.

Nick

Re: alloca is bad?

[Christopher G. Faylor]

On Sat, Nov 11, 2000 at 04:27:29PM +1100, Andrew Cagney wrote:
>Chris Faylor wrote:
>> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
>>>>Date: Thu, 9 Nov 2000 21:20:32 -0500
>>>>From: Christopher Faylor <cgf@redhat.com>
>>>>
>>>>I was surprised by this assertion and so I thought I'd ask for a
>>>>consensus here.  Should the use of alloca be deprecated in gdb?
>>>
>>>In my experience, there's nothing wrong with alloca as long as it is
>>>used for allocating small buffers.  The only consideration is that not
>>>every platform supports alloca.
>> 
>>But, since alloca is already entrenched in gdb and available in liberty
>>I don't think this is an issue, is it?
>
>There are a many entrenched practices in GDB and many of those we don't
>want to perpetuate.  Typically, these were either viewed as innocent
>short-cuts or simply as good ideas.  In hindsight (we've 15 years worth
>now :-) these practices turned out to be somewhat misguided.  Part of
>our penance is that on-going maintenance expense we incur when ever we
>touch the code.
>
>Consider Peter S's example as a case in point - it looked harmless :-)

I don't think that the fact that you can cut yourself with a knife means
that you eliminate all sharp objects from your premises.

YMMV,
cgf

Re: alloca is bad?

[Fernando Nasser]

Nick Duffek wrote:
> 
> On 11-Nov-2000, Andrew Cagney wrote:
> 
> >This brings up an additional, possibly relevent, point.  Given the code:
> 
> >       int a[size];
> 
> >vs
> >       int *const a = alloca (size * sizeof (int));
> >or     int *const a = (int *) alloca (size & sizeof (int));
> 
> >(er and there is even one in the above and no it wasn't contrived!) the
> >latter definitely has more potential error points (both when being
> >written and being maintained).  Coding pratices that minimize a
> >programmers error rate should be considered.
> 
> That's one of the strongest arguments in favor of alloca over malloc.  The
> programmer error potential in these two lines of code:
> 
>         int *const a = alloca (size * sizeof (int));
>         int *const a = malloc (size * sizeof (int));
> 
> is exactly the same, but adding free() in the malloc case adds much more
> potential for errors, as demonstrated by the popularity of tools for
> finding memory leaks.  The malloc case gets even more error-prone where we
> need to check for non-local exits and add cleanup chains.
> 

Meomory leak -> small problem, easy to identify the culprit.

Stack corruption -> big problem, difficult to know even where to start.



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: alloca is bad?

[Fernando Nasser]

Someone said that heap corruption was harder to track than stack
corruption.

I couldn't disagree more.  Many (most?) of the times the function tries
to return and gets a buggy return address and frame pointer.
It then crashes and you have no idea where it happened.

The heap contents won't make it into your stack related registers,
so when something tries to use the data and crashes you still have a starting
point (it may be much latter, but at least you have somewhere to start.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: alloca is bad?

[Nick Duffek]

Do we have a standard way to decide issues like this?  Perhaps there
should be a group of GDB developers who vote on coding standards and other
contentious technical issues.

On 11-Nov-2000, Fernando Nasser wrote:

>Meomory leak -> small problem, easy to identify the culprit.

>Stack corruption -> big problem, difficult to know even where to start.

It's not memory leaks vs. stack corruption, it's memory leaks + heap
corruption + coding errors vs. stack corruption.

Pseudo-mathematically, the pro-alloca claim is:

  memory leaks + heap corruption + coding errors > stack corruption

where ">" means "is worse than".  If heap corruption == stack corruption,
then they cancel out and the above becomes:

  memory leaks + coding errors > 0

which is obviously true.  So, is it true that heap corruption == stack
corruption?  Memory corruption badness can be quantified as:

  (likelihood of occurrence) * (difficulty in tracking down)

If we establish appropriate guidelines on maximum alloca sizes, then stack
corruption is no more likely than heap corruption, so roughly:

  heap corruption likelihood == stack corruption likelihood

You claim that stack corruption is harder to track down than heap
corruption.  I claim the opposite, based on personal experience and
arguments presented elsewhere in this thread.

But until someone posts hard numbers quantifying this question, I think
such claims aren't meaningful, so for now:

  heap corruption difficulty == stack corruption difficulty

which completes the "proof" of the original claim.  :-)

Incidentally, I disagree with:

>Meomory leak -> small problem, easy to identify the culprit.

When a leak is small, it's insidious.  GDB gets a bit more sluggish, but
not enough that anyone thinks to check for a memory leak.  Therefore,
leaks can go undetected for years.  Total GDB user time wasted:

  (tiny slowdown) * (entire GDB user population) * (years)

By contrast, memory corruption usually gets detected and fixed pretty
quickly.  Total GDB user time wasted:

  (time to revert to previous version) *
    (the few GDB users who found the corruption before it was fixed)

It wouldn't surprise me if the former were bigger than the latter.

Nick

Re: alloca is bad?

[Christopher Faylor]

On Sat, Nov 11, 2000 at 07:51:36PM +0000, Fernando Nasser wrote:
>Someone said that heap corruption was harder to track than stack
>corruption.
>
>I couldn't disagree more.  Many (most?) of the times the function tries
>to return and gets a buggy return address and frame pointer.
>It then crashes and you have no idea where it happened.

Someone, i.e., me, has pointed out that stack overruns happen when you
use auto arrays and pointers to auto variables.  I don't see how you can
use this as an argument unless you are advocating that we should only
use static variables.

cgf

Re: alloca is bad?

[Eli Zaretskii]

> Date: Sat, 11 Nov 2000 19:51:36 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> Someone said that heap corruption was harder to track than stack
> corruption.
> 
> I couldn't disagree more.  Many (most?) of the times the function tries
> to return and gets a buggy return address and frame pointer.
> It then crashes and you have no idea where it happened.

The same happens with overrunning malloc'ed buffers or free'ing the
same buffer twice: you get a corrupted chain of memory buffers in the
malloc-maintained pool of memory, and the program crashes at some
random point down the road, inside malloc or inside free.  The core
file contains no evidence about who corrupted the heap.  If you don't
have sources to malloc, you usually ned an malloc debugger to find the
villain.  However, many malloc debuggers increase the memory footprint
to such an extent that it becomes impractical to use them in large
programs which allocate and free memory all the time.

In contrast, with stack corruption, the crash is much more close to
the corruption point, usually a function call or two away, because the
stack is a single entity that gets exercised all the time, not
subdivided into buckets like in a typical malloc implementation.  It
is relatively easy to find the function which corrupted the stack,
e.g. by putting a watchpoint on the stack pointer register that
catches the moment when it is below the stack limit (assuming
expand-down stack).  Since registers can usually only be watched by
software watchpoints, knowing the approximate area where the offending
code should be is very important, otherwise running a program in
single-step can render this technique impractical.

Re: alloca is bad?

[Fernando Nasser]

Eli Zaretskii wrote:
> 
> (...)
> In contrast, with stack corruption, the crash is much more close to
> the corruption point, usually a function call or two away, because the
> stack is a single entity that gets exercised all the time, not
> subdivided into buckets like in a typical malloc implementation.  It
> is relatively easy to find the function which corrupted the stack,

The problem is that with a corrupted SP and FP you have no idea of where
it happened.  Doesn't matter if the crash was immediately after the fact,
all evidence of when it happened is wiped away.


> e.g. by putting a watchpoint on the stack pointer register that
> catches the moment when it is below the stack limit (assuming> expand-down stack).  Since registers can usually only be watched by
> software watchpoints, knowing the approximate area where the offending
> code should be is very important, otherwise running a program in
> single-step can render this technique impractical.

On the other hand, if you can get your execution path to repeat in a 
deterministic way so heap pieces are allocated in the same locations,
you can use hardware watchpoints (as it is memory, not registers).


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: alloca is bad?

[Fernando Nasser]

Christopher Faylor wrote:
> 
> On Sat, Nov 11, 2000 at 07:51:36PM +0000, Fernando Nasser wrote:
> >Someone said that heap corruption was harder to track than stack
> >corruption.
> >
> >I couldn't disagree more.  Many (most?) of the times the function tries
> >to return and gets a buggy return address and frame pointer.
> >It then crashes and you have no idea where it happened.
> 
> Someone, i.e., me, has pointed out that stack overruns happen when you
> use auto arrays

That is true.  Auto arrays are also cause of many stack corruption problems
as well.

But why add more sources?  Because there is evil doesn't justify to add 
MORE evil.

> and pointers to auto variables. 

That is bad programming.

> I don't see how you can
> use this as an argument unless you are advocating that we should only
> use static variables.
> 

I am saying nothing.  The gdb maintainers established this rule quite
some time ago.  I was one that had to back up some code (on one of my
early submissions) to remove calls to alloca (which I use in small programs
that I am the only one to write code to).

But I understood that in a program this size, with about 100+ people adding
code to it you must be EXTRA careful.  Thanks to this rules GDB, despite 
being now a much more sophisticated program, dumps core much less than it
used to do in the past, when the rules were less strict.

I am just defending the established rules here.  They are working and 
IMO they should not be changed unless there are very good reasons
and something close to consensus that they should be changed.



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: alloca is bad?

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> > Date: Sat, 11 Nov 2000 19:51:36 +0000
> > From: Fernando Nasser <fnasser@cygnus.com>
> >
> > Someone said that heap corruption was harder to track than stack
> > corruption.
> >
> > I couldn't disagree more.  Many (most?) of the times the function tries
> > to return and gets a buggy return address and frame pointer.
> > It then crashes and you have no idea where it happened.

This is more in line with my personal experience.  Something gets
trashed in the heap and it is a fairly well defined mechanical process
to first script a reproducable sequence that triggers the event and
secondly script a debug sequence that watches for the corruption. 
Typically a few well placed watchpoints and a very long lunch (while it
runs :-) does the trick.

On the other hand applying such a technique to a stack corruption is far
more complicated.  The very nature of a stack is that it is constantly,
and _annonymously_ being reused.  Typically far more complex tracing
sequences are needed to capture the corruption in progress.

To look at it another way, all heap accesses are explict while the stack
may either be accessed explictly or implicitly through function
call/return.

	enjoy,
		Andrew

Re: alloca is bad?

[Eli Zaretskii]

> Date: Sun, 12 Nov 2000 08:06:27 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> The problem is that with a corrupted SP and FP you have no idea of where
> it happened.  Doesn't matter if the crash was immediately after the fact,
> all evidence of when it happened is wiped away.

??? The core file will usually tell you the function in which it
crashed, and sometimes the one which called it (if you are lucky).
GDB doesn't need the stack information to tell you what function
crashed, the value of $pc should be enough.  At least usually.

Or am I missing something?

> On the other hand, if you can get your execution path to repeat in a 
> deterministic way so heap pieces are allocated in the same locations,
> you can use hardware watchpoints (as it is memory, not registers).

This is usually almost impossible without having sources to malloc.
Without the sources, you won't know where to put the watchpoints: all
you have is the garbled pointer in the register which caused the
crash, and the crash is usually not related to what your program did
at the point of the crash, so your own variables don't help.

Re: alloca is bad?

[Chris Faylor]

On Sun, Nov 12, 2000 at 07:16:58AM -0500, Eli Zaretskii wrote:
>> Date: Sun, 12 Nov 2000 08:06:27 +0000
>> From: Fernando Nasser <fnasser@cygnus.com>
>> 
>> The problem is that with a corrupted SP and FP you have no idea of where
>> it happened.  Doesn't matter if the crash was immediately after the fact,
>> all evidence of when it happened is wiped away.
>
>??? The core file will usually tell you the function in which it
>crashed, and sometimes the one which called it (if you are lucky).
>GDB doesn't need the stack information to tell you what function
>crashed, the value of $pc should be enough.  At least usually.
>
>Or am I missing something?

I've seen cases where the $pc was 0 and the frame pointer was screwed
up, making a back trace impossible.  That requires rerunning the program
and judicious use of display and step.  Whenever I have a stack problem,
I "display" the memory location that is being corrupted, rerun the
program, and "next" around until I see it fail.  When I see the failure,
I step into the offending function.

I've debugged many cases of stack corruption over my disgustingly long
career as a programmer.  I can't remember a specific case that troubled
me for very long.  I can remember, at least two cases where I spent days
trying to track down heap corruption problems, however.

Wasn't it mentioned that heap corruption was "easier" to track down
because there were tools for doing so on this thread?  Doesn't the fact
that there has to be special tools for debugging heap problems provide
enough evidence that heap corruption problems are not trivially
debugged?

>> On the other hand, if you can get your execution path to repeat in a 
>> deterministic way so heap pieces are allocated in the same locations,
>> you can use hardware watchpoints (as it is memory, not registers).
>
>This is usually almost impossible without having sources to malloc.
>Without the sources, you won't know where to put the watchpoints: all
>you have is the garbled pointer in the register which caused the
>crash, and the crash is usually not related to what your program did
>at the point of the crash, so your own variables don't help.

Right.  Also, the "if you can get your execution path to repeat in a
determinstic way" argument applies equally well to the stack.  If a
variable is getting clobbered, you find out where it has been stored
on the stack and monitor that location until you see it change.  You
may step by a function that causes the corruption but then you rerun
the program and try again.

In the case of stack problems you don't have to wonder if a function
call made thousands of instructions earlier could have been the culprit
that is screwing you up now.  If you see stack corruption it will be in
one of the functions on the stack.

I know that it is likely that no one here has much experience with
threaded programming, but I would much rather debug stack corruption in
a threaded environment than I would heap corruption.  If you have a
situation where more than one thread can be doing a malloc, as is the
case with cygwin, then you've thrown the whole "deterministic" thing out
of the window as far as the heap is concerned.  In threaded
applications, you *try* to use the stack for local storage as much as
possible so that each thread can have its own relatively isolated data
storage.

Again, I have to point out that this whole "stack problems are wicked
hard to debug" argument is specious, anyway.  All of the problems that
you have with an alloca'ed array apply to local arrays and pointers to
local variables.  Fernando has implied that using addresses to auto
variables is poor programming.  IMO, that statement is provably
incorrect since many UNIX system functions require pointers in their
parameter lists.  I've never heard anyone claim that the UNIX API
was broken.

Also, as far as debuggability and maintainability is concerned, I have a
hard time believing that anyone could assert that this:

    struct cleanup *chain;
    char *foo;

    foo = malloc (size);
    chain = make_cleanup (free, (void *) foo);
    .
    .
    . many lines of code
    .
    .
    do_cleanups (chain)

was more apt to be error-free and understandable than this:

    char *foo;
    foo = alloca (size);

As an exercise, imagine what would happen if I had gone with my
first, incorrect, inclination and done this:

    chain = make_cleanup (free, (void *) &foo);

Nick Duffek has requested that the procedures for determining
programming guidelines in GDB be clarified.  The feeling that I get from
Andrew and Fernando is that this alloca discussion has raged on before
and that the issue had been decided time ago.  I've checked the mailing
list archives and I don't see any definitive statements about this
subject, however.  If there is a document that says "Don't Use alloca
and Here's Why" no one has pointed it out yet.

Since at least four GDB maintainers have expressed their desire to
use alloca, is that an adequate quorom?  What's the procedure here?  Are
we eventually going to come to a decision and document it?  Or, are we
going to keep wrangling until someone gets tired?

cgf

Re: alloca is bad?

[Kevin Buettner]

On Nov 12,  1:39pm, Chris Faylor wrote:

> Since at least four GDB maintainers have expressed their desire to
> use alloca, is that an adequate quorom?  What's the procedure here?  Are
> we eventually going to come to a decision and document it?  Or, are we
> going to keep wrangling until someone gets tired?

I'm tired and I haven't even been wrangling.  :-)

Others of you have argued long and eloquently on the matter, so
I won't bother...  I will "vote" however:

1) I agree with those who think that debugging heap related corruption
   is frequently more difficult that debugging stack related corruption.

2) I think the use of alloca() should be allowed so long as the space
   to be allocated does not exceed some relatively small, but reasonable
   bound.

Kevin

Re: alloca is bad?

[Fernando Nasser]

Eli Zaretskii wrote:
> 
> > Date: Sun, 12 Nov 2000 08:06:27 +0000
> > From: Fernando Nasser <fnasser@cygnus.com>
> >
> > The problem is that with a corrupted SP and FP you have no idea of where
> > it happened.  Doesn't matter if the crash was immediately after the fact,
> > all evidence of when it happened is wiped away.
> 
> ??? The core file will usually tell you the function in which it
> crashed, and sometimes the one which called it (if you are lucky).
> GDB doesn't need the stack information to tell you what function
> crashed, the value of $pc should be enough.  At least usually.
> 
> Or am I missing something?
> 

Yes you are.  As Andrew explained in his message, if the stack is
corrupted the PC and FP can (and probably will) be clobbered with
the garbage when the function returns.

No backtrace, core dump or anything in this world will tell you where
you were when this happens as all information has been obliterated.

The GDB where command works by following the chain of stack frames
by using the saved values of frame pointers (or equivalent mechanisms)
to walk up the stack and give you that nice printout.  Without a point
to start, no chain can be recreated.


Bottom line: for most stack corruption problems, no "where" ("backtrace")


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: alloca is bad?

[Andrew Cagney]

Chris Faylor wrote:

> I've debugged many cases of stack corruption over my disgustingly long
> career as a programmer.  I can't remember a specific case that troubled
> me for very long.  I can remember, at least two cases where I spent days
> trying to track down heap corruption problems, however.

As they say, our energy efficency units have varied.

> Nick Duffek has requested that the procedures for determining
> programming guidelines in GDB be clarified.  The feeling that I get from
> Andrew and Fernando is that this alloca discussion has raged on before
> and that the issue had been decided time ago.  I've checked the mailing
> list archives and I don't see any definitive statements about this
> subject, however.  If there is a document that says "Don't Use alloca
> and Here's Why" no one has pointed it out yet.

Largely maintainer wim and folk law.

To re-iterate earlyer points.  The official problem with alloca() is
that it is very non-portable.  You can be pretty sure problems with this
date back to when GDB was first written and, consequently, the exact
details are now well and truely lost in time.

The BSD man page has:

  BUGS
     The alloca() function is machine dependent; its use is discouraged.

the Solaris man page has:
  WARNINGS
     ....

     alloca() is machine-, compiler-, and most  of  all,  system-
     dependent.  Its use is strongly discouraged.

With regard to multi-arch, the decision to allow alloca() was strictly
pragmatic - using it was far less error proned then trying to convert
all dynamic arrays to cleanups.  Part of the pragmatism behind it was
that it was thought that all the systems that had broken alloca()
implementations had long-ago been switched off.

> Since at least four GDB maintainers have expressed their desire to
> use alloca, is that an adequate quorom?  What's the procedure here?  Are
> we eventually going to come to a decision and document it?  Or, are we
> going to keep wrangling until someone gets tired?

See the threads originating from:

http://sources.redhat.com/ml/gdb/2000-11/msg00085.html

	Andrew

Re: alloca is bad?

[Andrew Cagney]

Kevin Buettner wrote:
> 
> On Nov 12,  1:39pm, Chris Faylor wrote:
> 
> > Since at least four GDB maintainers have expressed their desire to
> > use alloca, is that an adequate quorom?  What's the procedure here?  Are
> > we eventually going to come to a decision and document it?  Or, are we
> > going to keep wrangling until someone gets tired?
> 
> I'm tired and I haven't even been wrangling.  :-)

See:

http://sources.redhat.com/ml/gdb/2000-11/msg00085.html

as they say the process has already started. (The alloca() cat is
already out of the bag so a yes/no vote is pretty useless :-).

> 2) I think the use of alloca() should be allowed so long as the space
>    to be allocated does not exceed some relatively small, but reasonable
>    bound.

Covered.

	Andrew

Re: alloca is bad?

[Michael Meissner]

On Sat, Nov 11, 2000 at 05:06:19PM +1100, Andrew Cagney wrote:
> 	o	the suggestion that some platforms
> 		don't support even libiberty's alloca.
> 
> 		I'd be very interested in knowing the
> 		details of this.

Some (non-mainstream) systems allocate their stack in chunks from the heap.
When the stack is exhausted for the current chunk, they allocate some more
memory for the next chunk.  This doesn't work because the libiberty version of
alloca depends on the allocations being monotonically increasing or
decreasing.  When I was in the original X3J11 meetings, I remember this coming
up, and the original Crays used this allocation technique and possibly some of
the mainframe systems.

I've also heard of systems which use languages like Simula 67 that have
coroutines in them, each stack frame is allocated, and points back to the
parent frame.  Due to threading, there may be multiple pointers back to the
parent frame, and stack frames are garbage collected like everything else.
This is the so-called cactus stack that I mentioned.

Also in the original meetings, when I proposed alloca (and got shot down
basically 1 to everybody), Harris among others mentioned there was no way they
could ever have a variable sized stack.  Given C99 now has variable length
arrays, I dunno whether they planned to allocate VLAs or what.

Now, when RMS decided that alloca was a useful feature for the GNU system, he
knew it might be restricting which systems it could  be ported to.  Most
systems these days can support alloca in some form or another, but being
pedantic, most != all.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: alloca is bad?

[Michael Meissner]

On Sun, Nov 12, 2000 at 07:16:58AM -0500, Eli Zaretskii wrote:
> > Date: Sun, 12 Nov 2000 08:06:27 +0000
> > From: Fernando Nasser <fnasser@cygnus.com>
> > 
> > The problem is that with a corrupted SP and FP you have no idea of where
> > it happened.  Doesn't matter if the crash was immediately after the fact,
> > all evidence of when it happened is wiped away.
> 
> ??? The core file will usually tell you the function in which it
> crashed, and sometimes the one which called it (if you are lucky).
> GDB doesn't need the stack information to tell you what function
> crashed, the value of $pc should be enough.  At least usually.
> 
> Or am I missing something?

Yes, what usually happens is the return address that is saved on the stack is
corrupted (not necessarily the return address of the current function, but I've
seen corruption once or twice a couple of levels back).  When the function
whose return address is corrupted returns it jumps to the address.  If you are
somewhat lucky, the address is not a legal address and you get an immediate
core dump, though the pc is 0 or some such, which is totally useless, since on
most hardware, there isn't a come from address that says what was the pc before
the last jump.  If you aren't as lucky, it will jump to random code, and it may
be some time before you notice the corruption.

> > On the other hand, if you can get your execution path to repeat in a 
> > deterministic way so heap pieces are allocated in the same locations,
> > you can use hardware watchpoints (as it is memory, not registers).
> 
> This is usually almost impossible without having sources to malloc.
> Without the sources, you won't know where to put the watchpoints: all
> you have is the garbled pointer in the register which caused the
> crash, and the crash is usually not related to what your program did
> at the point of the crash, so your own variables don't help.

Or you can take one of the GPL mallocs and compile it on your system and link
it in.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: alloca is bad?

[Michael Meissner]

On Sun, Nov 12, 2000 at 08:48:43PM +1100, Andrew Cagney wrote:
> Eli Zaretskii wrote:
> > 
> > > Date: Sat, 11 Nov 2000 19:51:36 +0000
> > > From: Fernando Nasser <fnasser@cygnus.com>
> > >
> > > Someone said that heap corruption was harder to track than stack
> > > corruption.
> > >
> > > I couldn't disagree more.  Many (most?) of the times the function tries
> > > to return and gets a buggy return address and frame pointer.
> > > It then crashes and you have no idea where it happened.
> 
> This is more in line with my personal experience.  Something gets
> trashed in the heap and it is a fairly well defined mechanical process
> to first script a reproducable sequence that triggers the event and
> secondly script a debug sequence that watches for the corruption. 
> Typically a few well placed watchpoints and a very long lunch (while it
> runs :-) does the trick.
> 
> On the other hand applying such a technique to a stack corruption is far
> more complicated.  The very nature of a stack is that it is constantly,
> and _annonymously_ being reused.  Typically far more complex tracing
> sequences are needed to capture the corruption in progress.

I tend to agree with Andrew and against Chris in this regard.  For malloc
overruns, I typically just link in with -lefence or other tools, and it is
fairly obvious where the bug is.  In the past, for particularly nasty stack
overruns, I have changed the compiler to emit special debug code for prologues
and epilogues (of course nowadays, you can use -finstrument-functions to
accomplish the same behavior).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

[RFA] alloca coding standard

[Nick Duffek]

On 11-Nov-2000, Andrew Cagney wrote:

>To decide it is appropriate I think there need to be some clear and
>objective guidelines.

How about this?  The appended patch:

  - Documents the de facto coding standard of allowing limited alloca()
    allocations.  I've set the limit at 1 page per function; does anyone
    think it should be less, more, or specified in bytes instead of pages?

  - Briefly describes some of the issues that have been raised.

  - Moves an alloca (0) call from registers_changed() to
    wait_for_inferior(), so that the documentation can say:

      "For systems that use libiberty's alloca emulation, it is important
       that alloca be called when the stack is shallow to garbage-collect
       freed space.  As of this writing, GDB calls alloc (0) once per user
       command and once per inferior wait."

    It seemed more puzzling to say "GDB calls alloca (0) once per register
    cache invalidation", since that happens at less-predictable stack
    depths.

ChangeLog entries:

	* gdbint.texinfo (Alloca): New subsection.
	* infrun.c (wait_for_inferior): Call alloca (0).
	* regcache.c (registers_changed): Move alloca (0) call to
	wait_for_inferior() loop.

Nick

[patch follows]

Index: gdb/doc/gdbint.texinfo
===================================================================
diff -up gdb/doc/gdbint.texinfo gdb/doc/gdbint.texinfo
--- gdb/doc/gdbint.texinfo	Mon Nov 13 01:25:51 2000
+++ gdb/doc/gdbint.texinfo	Mon Nov 13 01:25:15 2000
@@ -2854,6 +2854,24 @@ visible to random source files.
 All static functions must be declared in a block near the top of the
 source file.
 
+@subsection Alloca
+
+@code{alloca} may be used for allocating up to a page of stack memory
+per function call.
+
+The size restriction is a compromise between the benefits of
+@code{alloca} and the risk of stack overflow, which can happen on
+systems that have fixed-length stack regions or bounds on frame sizes.
+
+For systems that use libiberty's @code{alloca} emulation, it is
+important that @code{alloca} be called when the stack is shallow to
+garbage-collect freed space.  As of this writing, @value{GDBN} calls
+@code{alloc (0)} once per user command and once per inferior wait.
+
+Because @value{GDBN} and other GNU programs use @code{alloca}, they are
+not portable to systems that neither provide a native @code{alloca} nor
+support libiberty's emulation of @code{alloca}.
+
 @subsection Clean Design
 
 In addition to getting the syntax right, there's the little question of
Index: gdb/infrun.c
===================================================================
diff -up gdb/infrun.c gdb/infrun.c
--- gdb/infrun.c	Mon Nov 13 01:25:58 2000
+++ gdb/infrun.c	Mon Nov 13 01:23:55 2000
@@ -1282,6 +1282,9 @@ wait_for_inferior (void)
 
   while (1)
     {
+      /* Garbage-collect libiberty's alloca() emulation.  */
+      alloca (0);
+
       if (target_wait_hook)
 	ecs->pid = target_wait_hook (ecs->waiton_pid, ecs->wp);
       else
Index: gdb/regcache.c
===================================================================
diff -up gdb/regcache.c gdb/regcache.c
--- gdb/regcache.c	Mon Nov 13 01:26:00 2000
+++ gdb/regcache.c	Mon Nov 13 01:24:18 2000
@@ -295,13 +295,6 @@ registers_changed (void)
 
   registers_pid = -1;
 
-  /* Force cleanup of any alloca areas if using C alloca instead of
-     a builtin alloca.  This particular call is used to clean up
-     areas allocated by low level target code which may build up
-     during lengthy interactions between gdb and the target before
-     gdb gives control to the user (ie watchpoints).  */
-  alloca (0);
-
   for (i = 0; i < ARCH_NUM_REGS; i++)
     register_valid[i] = 0;
 

Re: alloca is bad?

[Eli Zaretskii]

> Date: Sun, 12 Nov 2000 23:15:54 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> As Andrew explained in his message, if the stack is
> corrupted the PC and FP can (and probably will) be clobbered with
> the garbage when the function returns.

They could, yes; but in practice (at least in my experience), the
clobbered return address is caught by the OS protection in most cases,
so the program will GPF before the PC is garbled.

> Bottom line: for most stack corruption problems, no "where" ("backtrace")

In my experience, in most cases, there is in fact at least the frame
where it crashed.  You should be able to start debugging from there.

Re: alloca is bad?

[Eli Zaretskii]

> From: Michael Meissner <meissner@cygnus.com>
> Date: Sun, 12 Nov 2000 20:00:34 -0500
> 
> For malloc overruns, I typically just link in with -lefence or other
> tools, and it is fairly obvious where the bug is.

Except that there are programs where using Efence or similar tools is
impractical, because these libraries typically don't free memory when
the application calls `free' (to catch code which writes into free'd
memory).  This enlarges the memory footprint of such programs to the
extent that you cannot link with -lefence, because the program won't
run for more than a few moments, or not at all.

I'd expect GDB to be one of the programs where this approach is not
very practical, what with all the malloc'ing that goes on there.

In fact, we have such an elusive memory problem right now in Emacs
development sources.  It's been a couple of months since it was first
reported, and all of the Emacs developers have been hunting it ever
since, including lots of special-purpose code that was written
specifically for catching that bug.  The bug is still at large...

Re: [RFA] alloca coding standard

[Eli Zaretskii]

> Date: Mon, 13 Nov 2000 01:54:45 -0500
> From: Nick Duffek <nsd@redhat.com>
>
> diff -up gdb/doc/gdbint.texinfo gdb/doc/gdbint.texinfo
> --- gdb/doc/gdbint.texinfo	Mon Nov 13 01:25:51 2000
> +++ gdb/doc/gdbint.texinfo	Mon Nov 13 01:25:15 2000
> @@ -2854,6 +2854,24 @@ visible to random source files.

I have a few minor comments (assuming that the idea is accepted and
this text will be added to gdbint.texinfo):

> +@subsection Alloca

I suggest an index entry here, e.g. "@findex alloca usage".  (Hmm, it
looks like gdbint.texinfo doesn't print an index right now.  I will fix
that.)

> +@code{alloca} may be used for allocating up to a page of stack memory
> +per function call.

I'd suggest to say how much is a "page", at least for a couple of
popular architectures.  Not everyone is privy to intimate details of
system's memory allocation.

> +garbage-collect freed space.  As of this writing, @value{GDBN} calls
> +@code{alloc (0)} once per user command and once per inferior wait.
         ^^^^^
This should be `alloca', not `alloc'.

Finally, perhaps something should be said about functions that could
potentially be called recursively, where care should be taken not to
overflow the runtime stack, even if each invocation asks a single
page.

Re: [RFA] alloca coding standard

[Andrew Cagney]

Nick Duffek wrote:
> 
> On 11-Nov-2000, Andrew Cagney wrote:
> 
> >To decide it is appropriate I think there need to be some clear and
> >objective guidelines.
> 
> How about this?  The appended patch:

>   - Documents the de facto coding standard of allowing limited alloca()
>     allocations.  I've set the limit at 1 page per function; does anyone
>     think it should be less, more, or specified in bytes instead of pages?

I'd suggest first allowing for the discussion which is clarifying all
the issues to settle down and only after that start looking at something
recording guidelines for alloca.  (I really don't see the urgency on
this).

	Andrew

>   - Moves an alloca (0) call from registers_changed() to
>     wait_for_inferior(), so that the documentation can say:

This is a separate problem and not part of the patch.

Re: [RFA] alloca coding standard

[Fernando Nasser]

Nick Duffek wrote:
> 
>   - Moves an alloca (0) call from registers_changed() to
>     wait_for_inferior(), so that the documentation can say:
> 
>       "For systems that use libiberty's alloca emulation, it is important
>        that alloca be called when the stack is shallow to garbage-collect
>        freed space.  As of this writing, GDB calls alloc (0) once per user
>        command and once per inferior wait."
> 

What user command?  The GUI ad other script languages call random functions
in GDB.  And their command loops may even be in another process!

You must also explain how alloca(0) will work in libgdb.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: alloca is bad?

[Jim Blandy]

> I don't think that the fact that you can cut yourself with a knife means
> that you eliminate all sharp objects from your premises.

I wish you folks would be more straightforward.  Now I have to go
re-purchase all that cutlery.

Re: alloca is bad?

[Michael Meissner]

On Mon, Nov 13, 2000 at 06:12:58AM -0500, Eli Zaretskii wrote:
> > Date: Sun, 12 Nov 2000 23:15:54 +0000
> > From: Fernando Nasser <fnasser@cygnus.com>
> > 
> > As Andrew explained in his message, if the stack is
> > corrupted the PC and FP can (and probably will) be clobbered with
> > the garbage when the function returns.
> 
> They could, yes; but in practice (at least in my experience), the
> clobbered return address is caught by the OS protection in most cases,
> so the program will GPF before the PC is garbled.

That's not my experience, but I suspect different machines, different OSes....

> > Bottom line: for most stack corruption problems, no "where" ("backtrace")
> 
> In my experience, in most cases, there is in fact at least the frame
> where it crashed.  You should be able to start debugging from there.

This is assuming you have a valid frame.  On systems with a frame pointer, the
FP often times gets clobbered, just like the return address does, because both
get restored at the same time.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: alloca is bad?

[Michael Meissner]

On Mon, Nov 13, 2000 at 06:13:49AM -0500, Eli Zaretskii wrote:
> > From: Michael Meissner <meissner@cygnus.com>
> > Date: Sun, 12 Nov 2000 20:00:34 -0500
> > 
> > For malloc overruns, I typically just link in with -lefence or other
> > tools, and it is fairly obvious where the bug is.
> 
> Except that there are programs where using Efence or similar tools is
> impractical, because these libraries typically don't free memory when
> the application calls `free' (to catch code which writes into free'd
> memory).  This enlarges the memory footprint of such programs to the
> extent that you cannot link with -lefence, because the program won't
> run for more than a few moments, or not at all.

Yes I know, I assumed that would be obvious, particularly with efence which
allocates 2 pages per malloc request.  Its part of the reason why I have 1+
gigs of swap space on this machine, and will probably go to 2 or more the next
time I reogranize the disks.

> I'd expect GDB to be one of the programs where this approach is not
> very practical, what with all the malloc'ing that goes on there.

In terms of GCC, it tended to be obstacks that caused the most grief, because
they didn't work well with malloc checkers.  Fortunately, obstacks are mostly a
thing of the past these days in the compiler.

> In fact, we have such an elusive memory problem right now in Emacs
> development sources.  It's been a couple of months since it was first
> reported, and all of the Emacs developers have been hunting it ever
> since, including lots of special-purpose code that was written
> specifically for catching that bug.  The bug is still at large...

Bummer....

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: alloca is bad?

[Christopher G. Faylor]

On Mon, Nov 13, 2000 at 10:52:18AM -0500, Jim Blandy wrote:
>>I don't think that the fact that you can cut yourself with a knife
>>means that you eliminate all sharp objects from your premises.
>
>I wish you folks would be more straightforward.  Now I have to go
>re-purchase all that cutlery.

It's not just cutlery.  For a while, I actually had eliminated all electrical
appliances after I saw the consequences of a lightening strike to a tree.

Eventually, I decided that this was foolish, so I'm now allowing my family
to use flashlights and transistor radios.

cgf

[RFA] Move alloca(0) to wait_for_inferior() from registers_changed()

[Nick Duffek]

On 13-Nov-2000, Andrew Cagney wrote:

>Nick Duffek wrote:

>>   - Moves an alloca (0) call from registers_changed() to
>>     wait_for_inferior(), so that the documentation can say:

>This is a separate problem and not part of the patch.

Okay.  The appended patch moves an alloca (0) call from
registers_changed() in regcache.c to wait_for_inferior() in infrun.c.

The purpose of alloca (0) is to garbage-collect space freed by libiberty's
alloca implementation.  It is important that this garbage collection
occur at regular intervals when the stack is shallow.

At the moment, regcache.c has this comment preceding the alloca (0) call:

  /* Force cleanup of any alloca areas if using C alloca instead of
     a builtin alloca.  This particular call is used to clean up
     areas allocated by low level target code which may build up
     during lengthy interactions between gdb and the target before
     gdb gives control to the user (ie watchpoints).  */

It's not obvious that registers_changed() gets called regularly or at
shallow stack depths during interactions between gdb and the target.

But it is obvious that wait_for_inferior() loops regularly at shallow
stack depths during those interactions.

Therefore, it makes more sense to put the alloca (0) in the
wait_for_inferior() loop than in registers_changed().

ChangeLog entries:

	* infrun.c (wait_for_inferior): Call alloca (0).
	* regcache.c (registers_changed): Move alloca (0) call to
	wait_for_inferior() loop.

Okay to apply?

Nick

[patch follows]

Index: gdb/infrun.c
===================================================================
diff -up gdb/infrun.c gdb/infrun.c
--- gdb/infrun.c	Mon Nov 13 01:25:58 2000
+++ gdb/infrun.c	Mon Nov 13 01:23:55 2000
@@ -1282,6 +1282,9 @@ wait_for_inferior (void)
 
   while (1)
     {
+      /* Garbage-collect libiberty's alloca() emulation.  */
+      alloca (0);
+
       if (target_wait_hook)
 	ecs->pid = target_wait_hook (ecs->waiton_pid, ecs->wp);
       else
Index: gdb/regcache.c
===================================================================
diff -up gdb/regcache.c gdb/regcache.c
--- gdb/regcache.c	Mon Nov 13 01:26:00 2000
+++ gdb/regcache.c	Mon Nov 13 01:24:18 2000
@@ -295,13 +295,6 @@ registers_changed (void)
 
   registers_pid = -1;
 
-  /* Force cleanup of any alloca areas if using C alloca instead of
-     a builtin alloca.  This particular call is used to clean up
-     areas allocated by low level target code which may build up
-     during lengthy interactions between gdb and the target before
-     gdb gives control to the user (ie watchpoints).  */
-  alloca (0);
-
   for (i = 0; i < ARCH_NUM_REGS; i++)
     register_valid[i] = 0;
 

Re: [RFA] Move alloca(0) to wait_for_inferior() from registers_changed()

[Nick Duffek]

On 13-Nov-2000, I wrote:

>The appended patch moves an alloca (0) call from registers_changed() in
>regcache.c to wait_for_inferior() in infrun.c.

Whoops, I should have sent that to gdb-patches.  It's there now.

Nick

Re: alloca is bad?

[Nick Duffek]

On 12-Nov-2000, Michael Meissner wrote:

>For malloc overruns, I typically just link in with -lefence or other
>tools, and it is fairly obvious where the bug is.

For alloca overruns, one could get similar results by recompiling with
libiberty's alloca and linking with -lefence.

Nick

Re: alloca is bad?

[Michael Meissner]

On Mon, Nov 13, 2000 at 03:20:23PM -0500, Nick Duffek wrote:
> On 12-Nov-2000, Michael Meissner wrote:
> 
> >For malloc overruns, I typically just link in with -lefence or other
> >tools, and it is fairly obvious where the bug is.
> 
> For alloca overruns, one could get similar results by recompiling with
> libiberty's alloca and linking with -lefence.

That won't work, since alloca is a builtin provided by GCC.  If GCC is detected
as the compiler at configuration time, then alloca is not even built into
libiberty.  On systems like Linux and *BSD, there is typically no other
compiler except GCC.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: [RFA] alloca coding standard

[Nick Duffek]

Thanks for the comments.  Here's an updated patch that I hope addresses
the concerns raised.  In particular:

On 13-Nov-2000, Eli Zaretskii wrote:

>I suggest an index entry here, e.g. "@findex alloca usage".

Agreed.  I also added a @cindex entry.

>I'd suggest to say how much is a "page", at least for a couple of
>popular architectures.

I changed it to "1 page or 512 bytes, whichever is larger" so that
developers needn't know the page size.

>This should be `alloca', not `alloc'.

Whoops, thanks.

>Finally, perhaps something should be said about functions that could
>potentially be called recursively

I added a cautionary sentence about recursive functions.

On 13-Nov-2000, Andrew Cagney wrote:

>I'd suggest first allowing for the discussion which is clarifying all
>the issues to settle down and only after that start looking at something
>recording guidelines for alloca.

After the discussion settles down, I'll resubmit the patch if it still
seems applicable.

On 13-Nov-2000, Fernando Nasser wrote:

>What user command?  The GUI ad other script languages call random functions
>in GDB.  And their command loops may even be in another process!

Good point.  I reworded the documentation to cover more interfaces and to
be less specific about where they call alloca (0).

Nick

[patch follows]

Index: gdb/doc/gdbint.texinfo
===================================================================
diff -up gdb/doc/gdbint.texinfo gdb/doc/gdbint.texinfo
--- gdb/doc/gdbint.texinfo	Mon Nov 13 15:08:57 2000
+++ gdb/doc/gdbint.texinfo	Mon Nov 13 15:08:06 2000
@@ -2854,6 +2854,31 @@ visible to random source files.
 All static functions must be declared in a block near the top of the
 source file.
 
+@subsection Alloca
+@findex alloca
+@cindex alloca
+
+@code{alloca} may be used for allocating up to one page or 512 bytes of
+memory per function call, whichever is larger.
+
+The size limit is a compromise between the benefits of @code{alloca} and
+the risk of stack overflow, which can happen on systems that have
+fixed-length stack regions or bounds on frame sizes.
+
+In deeply recursive functions, a smaller limit may be necessary to avoid
+overflowing the stack.
+
+For systems that use libiberty's @code{alloca} emulation, it is
+important that @code{alloca} be called when the stack is shallow to
+garbage-collect freed space.  Toward that end, each interface to the
+@value{GDBN} core --- for example, GDBTK, libgdb, and the text console
+--- should ensure that @code{alloca (0)} is called periodically.  In
+addition, @value{GDBN} calls @code{alloca (0)} once per inferior wait.
+
+Because @value{GDBN} and other GNU programs use @code{alloca}, they are
+not portable to systems that neither provide a native @code{alloca} nor
+support libiberty's emulation of @code{alloca}.
+
 @subsection Clean Design
 
 In addition to getting the syntax right, there's the little question of

Re: [RFA] alloca coding standard

[Kevin Buettner]

On Nov 13,  3:36pm, Nick Duffek wrote:

> >I'd suggest to say how much is a "page", at least for a couple of
> >popular architectures.
> 
> I changed it to "1 page or 512 bytes, whichever is larger" so that
> developers needn't know the page size.

I think we ought to just pick a number (in bytes) and not mention
pages at all.  

The last time I checked, the default page size on Linux/IA-64 was
16KB.  It's possible to recompile the kernel to use 64KB pages.  My
point is that it would be possible for someone to submit patch using
alloca() which meets your proposed guidelines (on the architecture
upon which the patch was developed), but which aren't reasonable for
generic code.

Kevin

Re: [RFA] alloca coding standard

[Nick Duffek]

On 13-Nov-2000, Kevin Buettner wrote:

>I think we ought to just pick a number (in bytes) and not mention
>pages at all.  

I agree.  I'll rework the patch to specify 512 bytes or whatever number
the group thinks is reasonable.

Nick

Re: alloca is bad?

[Nick Duffek]

On 13-Nov-2000, Michael Meissner wrote:

>That won't work, since alloca is a builtin provided by GCC.

That can be disabled by compiling with -fno-builtin.

>If GCC is detected as the compiler at configuration time, then alloca is
>not even built into libiberty.

True, but that's easy to circumvent.

Using -lefence or other debugging mallocs to debug alloca overruns isn't
as easy as a simple relink, but it doesn't seem fundamentally difficult.

Nick

Re: alloca is bad?

[Michael Meissner]

On Mon, Nov 13, 2000 at 04:29:41PM -0500, Nick Duffek wrote:
> On 13-Nov-2000, Michael Meissner wrote:
> 
> >That won't work, since alloca is a builtin provided by GCC.
> 
> That can be disabled by compiling with -fno-builtin.

It isn't as simple as that with GNU software, which generally has code like the
following in an include file:

	#if defined(__GNUC__) && !defined(C_ALLOCA)
	# ifndef alloca
	#  define alloca __builtin_alloca
	# endif
	#else /* ! defined (__GNUC__) */

(ie, if the compiler is GCC always use the builtin function).  You probably
also need to rebuild the whole app, and not just relink it.

> >If GCC is detected as the compiler at configuration time, then alloca is
> >not even built into libiberty.
> 
> True, but that's easy to circumvent.
> 
> Using -lefence or other debugging mallocs to debug alloca overruns isn't
> as easy as a simple relink, but it doesn't seem fundamentally difficult.
> 
> Nick

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: alloca is bad?

[Jim Blandy]

Nick Duffek <nsd@redhat.com> writes:

> 
> On 12-Nov-2000, Michael Meissner wrote:
> 
> >For malloc overruns, I typically just link in with -lefence or other
> >tools, and it is fairly obvious where the bug is.
> 
> For alloca overruns, one could get similar results by recompiling with
> libiberty's alloca and linking with -lefence.

Usually, by the time I've discovered the problem is related to alloca
at all, I've found the bug anyway.

I guess I could just always build with the malloc-based alloca and
-lefence, but...

Re: [RFA] alloca coding standard

[Jim Blandy]

Nick Duffek <nsd@redhat.com> writes:

> 
> On 13-Nov-2000, Kevin Buettner wrote:
> 
> >I think we ought to just pick a number (in bytes) and not mention
> >pages at all.  
> 
> I agree.  I'll rework the patch to specify 512 bytes or whatever number
> the group thinks is reasonable.

Often the size will be data-dependent, and not under the control of
the person submitting the patch at all.  Is a register file 512 bytes
long?

It must be a judgement call, so I don't see much point in being
precise.  Rather, the documentation should explain the issues, so the
person can make an educated decision.

Re: [RFA] alloca coding standard

[Michael Meissner]

On Tue, Nov 14, 2000 at 10:42:28AM -0500, Jim Blandy wrote:
> 
> Nick Duffek <nsd@redhat.com> writes:
> 
> > 
> > On 13-Nov-2000, Kevin Buettner wrote:
> > 
> > >I think we ought to just pick a number (in bytes) and not mention
> > >pages at all.  
> > 
> > I agree.  I'll rework the patch to specify 512 bytes or whatever number
> > the group thinks is reasonable.
> 
> Often the size will be data-dependent, and not under the control of
> the person submitting the patch at all.  Is a register file 512 bytes
> long?
> 
> It must be a judgement call, so I don't see much point in being
> precise.  Rather, the documentation should explain the issues, so the
> person can make an educated decision.

Ummm, it is those data dependencies that are the root of the problem.  Didn't
we just have somebody post that in bfd-land, they had an alloca based on the
number of sections?  In a.out type formats, you get 3 sections, in normal ELF
you might get 10 or so, until the user does -ffunction-sections and/or
-fvariable-sections, and suddenly now, the alloca is for thousands of elements,
if not millions.

So, IMHO (or IMAO if you prefer), alloca should not be used on with any value
that is data dependent, unless it can be shown that the value will never be
bigger than your max size for alloca (for any possible machine, including those
not yet written for machine independent code).  Thus I would say in MI code,
you should not use alloca based on the number of registers, but it is perfectly
fine to use it in MD code....

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: [RFA] alloca coding standard

[Jim Blandy]

> > Often the size will be data-dependent, and not under the control of
> > the person submitting the patch at all.  Is a register file 512 bytes
> > long?
> > 
> > It must be a judgement call, so I don't see much point in being
> > precise.  Rather, the documentation should explain the issues, so the
> > person can make an educated decision.
> 
> Ummm, it is those data dependencies that are the root of the problem.  Didn't
> we just have somebody post that in bfd-land, they had an alloca based on the
> number of sections?  In a.out type formats, you get 3 sections, in normal ELF
> you might get 10 or so, until the user does -ffunction-sections and/or
> -fvariable-sections, and suddenly now, the alloca is for thousands of elements,
> if not millions.
> 
> So, IMHO (or IMAO if you prefer)

You're so A, Michael. :)

> alloca should not be used on with any value that is data dependent,
> unless it can be shown that the value will never be bigger than your
> max size for alloca

It seems to me that if you can establish a maximum size, you might as
well simply declare the array to be that large to begin with, and
forget about alloca altogether.  Your constraint sounds like "You may
only use alloca when it's not needed."  :)

Re: [RFA] alloca coding standard

[Andrew Cagney]

Jim Blandy wrote:

> > alloca should not be used on with any value that is data dependent,
> > unless it can be shown that the value will never be bigger than your
> > max size for alloca
> 
> It seems to me that if you can establish a maximum size, you might as
> well simply declare the array to be that large to begin with, and
> forget about alloca altogether.  Your constraint sounds like "You may
> only use alloca when it's not needed."  :)

It is the old attage of do it right the first time (in which case
nothing is ever done :-).  It is a case of tradeing off a quick fast
easy solution with a more permenant robust one.  The decision to use
alloca() to resolve multi-arch problems being an example of how
difficult making that that tradeoff can be.

I suspect that there are plenty of things that can still (ab)use alloca
(string routines come to mind).

In terms of documenting this, I'd personally first let the debate settle
down a little (on the internet everything moves very slowly, you can't
decide anything in less than a week :-) and then just clearly document
the objective points that should be considered when using the function.

The two points I'd be taking from this part of the thread are that:

	o	an arbitrary limit of one page
		is just that.  More concrete
		observations such as ``look you've
		got no more than 512k of total
		stack to play with so alloca()ing
		very large chunks of memory very
		early on is likely to blow the stack.

	o	care should be taken when alloc()ing
		data structures based on external
		inputs.

	Andrew

Re: [RFA] alloca coding standard

[Eli Zaretskii]

> Date: Mon, 13 Nov 2000 15:36:40 -0500
> From: Nick Duffek <nsd@redhat.com>
>
> On 13-Nov-2000, Eli Zaretskii wrote:
> 
> >I suggest an index entry here, e.g. "@findex alloca usage".
> 
> Agreed.  I also added a @cindex entry.

Thanks.  However, having a "@cindex alloca" in addition to
"@findex alloca" is not a good idea: it generates identical index
entries (albeit typeset in different fonts) in the printed version.

Even in the on-line version, and even if the various indices are in
separate nodes (which is not at all certain for a small document such
as gdbint.texi, where it is customary to use @syncodeindex to get all
indices together), it is not very useful, because index-searching
commands will find an entry in any index.  The situation you probably
had in mind, where a user searches for an entry by manually browsing
the Index node, should not be the norm, but an exception: one should
search the index by using the index-searching commands.

Other than that, the changes for the docs can go in, once there's an
agreement on the subject matter.

Re: [RFA] alloca coding standard

[Eli Zaretskii]

> Date: Mon, 13 Nov 2000 16:24:49 -0500
> From: Nick Duffek <nsd@redhat.com>
> 
> On 13-Nov-2000, Kevin Buettner wrote:
> 
> >I think we ought to just pick a number (in bytes) and not mention
> >pages at all.  
> 
> I agree.  I'll rework the patch to specify 512 bytes or whatever number
> the group thinks is reasonable.

I think 512 bytes is too restricting. 1K or even 2K should not harm
anything.  (My criterion is the maximum size of an automatic array
that I would use without too much hesitation.)

Re: [RFA] alloca coding standard

[Christopher Faylor]

On Wed, Nov 15, 2000 at 06:20:47AM -0500, Eli Zaretskii wrote:
>> Date: Mon, 13 Nov 2000 16:24:49 -0500
>> From: Nick Duffek <nsd@redhat.com>
>> 
>> On 13-Nov-2000, Kevin Buettner wrote:
>> 
>> >I think we ought to just pick a number (in bytes) and not mention
>> >pages at all.  
>> 
>> I agree.  I'll rework the patch to specify 512 bytes or whatever number
>> the group thinks is reasonable.
>
>I think 512 bytes is too restricting. 1K or even 2K should not harm
>anything.  (My criterion is the maximum size of an automatic array
>that I would use without too much hesitation.)

In my particular patch, which started all of this, I essentially did a
"strdup" of the gdb command from a 'thread apply'.  In this case, there
is no way that you can guarantee that the command will be any length,
even though it is unlikely to reach 2K.

Does this kind of situation need to be spelled out?  I'm beginning to
think that Jim Blandy's point of view is corret.  If we decide that
alloca is acceptable maybe we just need to document all of its pitfalls
and leave the rest to the intelligence of the programmer.

cgf