Re: unbounded recursive call in a shell script crashes zsh

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Apr 13,  6:01pm, Jeremie Roquet wrote:
} Subject: Re: unbounded recursive call in a shell script crashes zsh
}
} 2017-04-13 17:21 GMT+02:00 Jeremie Roquet <jroquet@xxxxxxxxxxxxx>:
} > Hence a total of 5856 bytes per recursion, or 5719 kiB for 10000 recursions.
} 
} Sorry, I meant 1000 recursions, obviously.
} 
} Here are the numbers when compiling using -O3 instead of -O0 -ggdb -
} [...] 
} Hence an even higher total of 13344 bytes per recursion, or 13032 kiB
} for 1000 recursions.

Much of the zsh internals are written in a recursive-call coding style;
e.g. the parser is a modified recursive-descent algorithm, and as you
have just demonstrated the execution engine replays the resulting parse
tree by recusive traversal.  So zsh is going to consume stack, maybe
more of it than other shells.

The best setting of --enable-max-function-depth devolves somewhat to
black magic.  There's unfortunately no way for the builder of a pre-
compiled package such as an RPM to know what stack limit will be in
place when zsh starts up, the compiler options affect how much stack
is needed, there is no way for zsh to tell at run time that stack is
about to run out, and there is no useful way to recover once the stack
has been filled.

This has been debated several times in the past, there's probably a
way to find it by searching the archives.  At one point the max depth
was reduced from something like 4096 to the current default of 1000,
because too many of those out-of-stack crashes were happening.

If not for the variable thrown in by the compiler options it might be
possible for zsh to estimate a value for max function depth at the
time it starts up, by examining the current limits, but there's also
no guarantee that the limit settings reflect the actual amount of
stack available.

If someone has a brilliant solution for this, we'd be glad to use it.