Zsh Mailing List Archive
Messages sorted by:
Re: unbounded recursive call in a shell script crashes zsh
- X-seq: zsh-workers 40959
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Kamil Dudka <kdudka@xxxxxxxxxx>
- Subject: Re: unbounded recursive call in a shell script crashes zsh
- Date: Tue, 11 Apr 2017 19:12:41 -0700
- Cc: "Zsh Hackers' List" <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject:cc :mime-version; bh=Zj58sCN/X3JlSkXB0gnKx2AZ+IE90NJBJA80cEGJcw8=; b=F8OqLSaCa1Y1Vx+506GPuA0aOLtU/gqOhaD2iSeZ642zTKt7mudAi6nqf+h+Ex43GD WbEl6Hml5EdBmHNCD2LUxQyN6p9ygHXdiaoQ2n0trLlfG9c+gMRcVBC8sNu7pzVyvIrY v4wLCY0HMa0Mmjxia7QVHcAN5ifSKcdoCs/0kiwG0JpiYddAmBAv2HS3aYnCJzqBFCFr bDH1T6d5j0ftdynnVelDqTwhpCVC4+JA1NTeYCmf3ZZBTCA4y1aFzyxN6pYXeRafSoNd y4i3XuDVSUF9cgX4eyWoeO6aYV6csjGNHqzSXtqoWrBxoH99YNzUev5noFgXgXgqllMR 992w==
- In-reply-to: <1569411.Kln6y2GJnM@kdudka-nb>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <2960832.nVDpiBkaWZ@kdudka-nb> <CAFOazAOTiUu8w9ZHZnhpBBtQ5FHj-Jb1OLxGf6eO4S-9DS7=fQ@mail.gmail.com> <CAFOazAM_2dX4F-5i5ER61EFf8WmO-43CnNbJq3CZWQHdaG78=A@mail.gmail.com> <1569411.Kln6y2GJnM@kdudka-nb>
On Apr 11, 4:38pm, Kamil Dudka wrote:
} So the difference is caused by the fact that recent versions of zsh are
} more hungry on stack, so the stack allocation limit is exceeded before the
} shell call recursion limit is reached.
Actually more recent versions should be *less* hungry because we no
longer use alloca() as the default for many local arrays (unless your
zsh was compiled with --enable-stack-allocation).
However, a LOT has changed since 4.3.11. For example the warning about
"recursion limit exceeded" is from an entirely different part of the
code than "maximum nested function" -- the limit that was being hit in
4.3.11 is never reached with 5.3.1, so there's no way to tell whether
the older version might also have overflowed the stack.
In fact 4.3.11 running out of job table space means that it consumed
all malloc() memory before consuming all of the stack; 5.3.1 is much
better about heap footprint.
Messages sorted by: