Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14696
| From | Mike Gerwitz <mtg@gnu.org> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Segfault on recursive trap/kill |
| Date | 2018-10-07 13:21 -0400 |
| Message-ID | <mailman.1807.1538933144.1284.bug-bash@gnu.org> (permalink) |
| References | (1 earlier) <25389056-9fcf-1d31-36d8-13098769a43a@case.edu> <874ldy1vka.fsf@gnu.org> <20181006210450465282080@bob.proulx.com> <87y3baxpy4.fsf@gnu.org> <CAHdzDnZcEzKYkDTK=Cs6cep3h+3nBoEbi=oi148fOKsM=KBVfQ@mail.gmail.com> |
[Multipart message — attachments visible in raw view] - view raw
On Sun, Oct 07, 2018 at 08:52:25 +0200, Valentin Bajrami wrote:
> As earlier expained, you are calling foo function recursively. To mitigate
> this behaviour you simple set FUNCNEST=<N> foo() { foo; }; foo where N
> denotes the number of nested functios to be called.
This is perfect and clear behavior, actually:
$ FUNCNEST=10; foo() { foo; }; foo
bash: foo: maximum function nesting level exceeded (10)
If bash were to set a default value for FUNCNEST then a useful error
would be provided rather than segfaulting (and possibly triggering a
coredump). Of course, if bash itself is sharing a stack with the
interpreter, then it's hard to come up with a good predetermined value.
FUNCNEST doesn't seem to work with the issue of recursive traps, though
(understandably).
--
Mike Gerwitz
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: Segfault on recursive trap/kill Mike Gerwitz <mtg@gnu.org> - 2018-10-07 13:21 -0400
csiph-web