From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6527 invoked by alias); 15 Apr 2017 16:14:35 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40976 Received: (qmail 10469 invoked from network); 15 Apr 2017 16:14:35 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f42.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.213.42):SA:0(0.5/5.0):. Processed in 2.328893 secs); 15 Apr 2017 16:14:35 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_SPAM,SPF_PASS, T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.42 as permitted sender) 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=3wTd83JjHFEzBb8QSN7s6QXeJXtPlAMPAQelehY10r0=; b=MaYQVdqaG/KQ/NVT9YTAMyghl3sCfFBChaDYIkOgIUzDESX3+dNAruUiQW6Wpo7Ggy fkMiupUlJG9CzAW1oYgaywO2TD8KH08UzRmZdjbG+T765ZecOVmJ3Q3TiWzVh0XKmOqm oULVIaR9zAVCNrisGqdSbQtJzQ+GnlVcupGA09mSiWc1o/9ADKUgrnw26cr5wh/WxWrD 91i27hAHKFdeNJzbgfHBGjSL7ojL5/PPuZbRy0uNQBzmcMsGT48GBXFN7fA5wIC5iA5c 5fY53CplvWIvsMTa0PVNvQvtZQeMxg5evqmIA/nfz6waY4f3BCz2rkJXHXI0AkWKiY+h qbWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:cc:mime-version; bh=3wTd83JjHFEzBb8QSN7s6QXeJXtPlAMPAQelehY10r0=; b=XNzyMitgmlcuZrL2r5yEtyTDvfq9Nq60zCuJjUgECkflrA+fuLsmoqRMPwF2SChRUE 7bQDhX1xef7uWEmGKj+EjsbDNu/QK2VG2NUOpcn6JAW3RXbCEpoIORQYpDkgu48PAcXw gHrGnA8POF3nqIXnQQgTxa3F+H/VmwxAO2jFARy+e6ltFSLWFGzlUY4X+TE42uLkuSvp DqPPbrM8vGuu3InhG44uGfd54JkfuI2tHypp6HARRN0xOXqcYE77q0/e2lRyUCh1BzA/ Qk+uTU3dKkkjoFaxdr/hN4JYlqHGxpcAXKk4VYizNSrCR6d4ChFROM0pwdi8WEfU02gF vR1Q== X-Gm-Message-State: AN3rC/65bNtWM+BmmDKdOxOjPUW5lU2BfLwjAC7EQSSnbrpScGZP4ck9 CU87oxD0qZR6gQ== X-Received: by 10.31.134.196 with SMTP id i187mr5618256vkd.56.1492272868763; Sat, 15 Apr 2017 09:14:28 -0700 (PDT) From: Bart Schaefer Message-Id: <170415091456.ZM22606@torch.brasslantern.com> Date: Sat, 15 Apr 2017 09:14:56 -0700 In-Reply-To: Comments: In reply to Jeremie Roquet "Re: unbounded recursive call in a shell script crashes zsh" (Apr 13, 6:01pm) References: <2960832.nVDpiBkaWZ@kdudka-nb> <2420758.31stuSQeAV@kdudka-nb> <2350280.olGvC23INb@kdudka-nb> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "zsh-workers@zsh.org" Subject: Re: unbounded recursive call in a shell script crashes zsh Cc: Kamil Dudka MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 : } > 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.