Re: Crash when completion script call itself.

[Peter Stephenson <p.stephenson@samsung.com>]

On Tue, 03 Oct 2017 17:23:45 +0200
Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> I still have issues with posting to the mailing list (tends to take
> several resends) so I've not bothered...
> 
> You wrote:
> > This looks like low-hanging fruit.  Allocating memory to save over a
> > shell function happens just at the point where we've created the new
> > heap for the function, which expires immediately after the call.  The
> 
> I'm not sure what you mean by "save over a shell function"? Do I
> understand this as just using the heap instead of the stack for whatever
> needs to be saved for each nested function? Is that so that we can
> detect the eventual out-of-memory condition and can report it or to try
> to maximise the possible number of recursions? Either way, it could do
> with a comment to make the purpose clear.

It's just to minimise stack usage.  The fact the data is going somewhere
other than the stack doesn't obviously need a comment, but I'll note the
change in case someone sees odd effects and starts looking for a cause.

If someone finds pathological behaviour with this, it's not a huge gain
anyway so could be abandoned.

> I'd have thought we could compress the data somewhat. In particular the
> opts array must be around 200 bytes. That could be divided by eight with
> bit fields or reduced near to nothing for functions that don't do setopt
> localoptions.

That's definitely going to impact on the time taken.  If someone wants
to start looking at real trade-offs of this sort they're welcome, but
I'm not going anywhere near this.  200 bytes over 1000 functions is not
huge by the standards of modern PC non-stack memory (I've taken off my
embedded programming hat which is quite tightly fitting anyway...).

> I also wonder if funcsave might be combined with funcstack
> somehow: are both a stack of function calls?

funcstack and funcsave are there for rather different purposes.
funcstack is exposed to give a user-visible state; it's not necessarily
constrained to grow or shrink within execshfunc().  funcsave is the
dirty washing inside execshfunc() there's no obvious reason to expose.

pws