From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8486 invoked by alias); 3 Oct 2017 17:55:16 -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: 41806 Received: (qmail 20163 invoked by uid 1010); 3 Oct 2017 17:55:16 -0000 X-Qmail-Scanner-Diagnostics: from mail-qk0-f178.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.220.178):SA:0(-1.4/5.0):. Processed in 1.619599 secs); 03 Oct 2017 17:55:16 -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=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM, 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: mikachu@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q83eBeNhCYJ3jr9mYzfRjQCd2R3DqChVwG9beovHn18=; b=uCUBinfotWFJf6SC8b+Ue3Z+CGzJRDpHnWjXfZ8LHyu+jY8Fqas1HlLfIQNBrPaeav SE1vDz7VaArgQvd9uDfmttx7ZxfpyhgNg36QwUvUXOSNDVkNf1ZrWRmHy6xaoqUsqa/F gWYZua6xbOum0uiSdGS7rTcPNRsLi9vCbeIwZIuSpOLw53TH8kySdNaC4/GsS+bBUjX6 8MWnq9nkFbVOUSFNpYZGsPjQcwImz60Y2VW596wLl+H51Hukcaa0SciYHE8O4XuH2m3j sHRMgPIONS2U4n0lWFBTkXnssYPL3bFN6zKBRRI5DCmDF7V/shLWZ7NGdMCG/U9H0ZsQ ZWnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q83eBeNhCYJ3jr9mYzfRjQCd2R3DqChVwG9beovHn18=; b=qjo82YXsymM6rpT1RjCLJe6hfw9jlRwhIXfMyTqfKo2uQyYgI405p8QLIzeHhixUZK l+rFxVnxskQyBllrYvSPIkllhDwe9ufhU5WvNjk4mBJ6zSC+sFA+ZfJbYZRJ6+GV5hvJ dVMLT+T8m4/QR11m77NZ8jduzBiQV4LtAvb+GuHPHkxyjqeBHftfo/p3DRAd4ZVe1c+e 1DYuTgjswYzWWNQCXxxyZEpkKWkdYkft/KGxzT8iT9jaOHR1fuH/xNXwuAwL7mZGATVN LPJsU5fS9bHwPA45IW0qJVD1j002S2vndRrkep14Axuu53jQHIHEUaHeOOmOw5uYDWX7 WeIQ== X-Gm-Message-State: AMCzsaXQL+MK2SfgUpXQ43KgnrmQCAWfF/Ucq+FqR8RC7lmRHtr0seWr ydh4Za11rWQB4+cDbowd8AqAVK4mrbM9xA/ERdan8A== X-Google-Smtp-Source: AOwi7QD5t8lPt/40NOOU4k0KcqLWsutx5WW6vlR1rxTpJpARPdsV0Jc8+8gnQP0mdGolF72oGcH3oKiyiNd/1QfLiVw= X-Received: by 10.55.101.4 with SMTP id z4mr7205633qkb.114.1507053308806; Tue, 03 Oct 2017 10:55:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <2309766.fAIUzOSDAY@kdudka-nb> References: <20170929151614.56fd9cff@pwslap01u.europe.root.pri> <20171002164018.699d03d4@pwslap01u.europe.root.pri> <2309766.fAIUzOSDAY@kdudka-nb> From: Mikael Magnusson Date: Tue, 3 Oct 2017 19:55:07 +0200 Message-ID: Subject: Re: Crash when completion script call itself. To: Kamil Dudka Cc: Peter Stephenson , zsh workers Content-Type: text/plain; charset="UTF-8" On Tue, Oct 3, 2017 at 4:45 PM, Kamil Dudka wrote: > On Monday, October 2, 2017 5:40:18 PM CEST Peter Stephenson wrote: >> On Fri, 29 Sep 2017 15:16:14 +0100 >> >> Peter Stephenson wrote: >> > I see this flag introduces a heuristic based on frame size, so tweaking >> > memory management internally might have a similar but more controllable >> > effect; on the other hand, it simultaneously removes any easy trade-off >> > you can make directly using compiler flags, and I'm not keen on >> > introducing #ifdef's where one branch would be underused and rot. >> >> 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 >> allocation itself should take very little time and on most architectures >> accessing the structure should have a similar overhead to accessing the >> stack. > > I was experimenting with a similar, slightly smaller, patch in April: > > http://www.zsh.org/mla/workers/2017/msg00630.html > > Now I tried to run the following command on my system: > > % FUNCNEST=4096 Src/zsh -c 'i=0; fn() { print $(( ++i )); fn; }; fn' > > With the current upstream HEAD, it counted to 1180. With my old patch, > it counted to 1224. With your current patch, it counted to 1242. > > The difference becomes slightly more significant when zsh is compiled > with -fconserve-stack. Then it counts to 2682 with the current version > and 3024 with your patch applied. If you want to do very deep nesting you can always increase the stack limit with ulimit -s (it's 8192kB on most distributions by default I believe). For example if I set it to 256 the above command only counts to 29, with ulimit -s unlimited I got this cool error with a higher FUNCNEST set: 16380 16381 16382 16383 16384 fn: maximum nested function level reached; increase FUNCNEST? parse.c:2745: Overlarge EPROG nref parse.c:2745: Overlarge EPROG nref parse.c:2745: Overlarge EPROG nref parse.c:2745: Overlarge EPROG nref but looking at the code that's just a debug code error, it only compares with the defined limit rather than the runtime limit. With a very high FUNCNEST it just keeps running until I run out of physical RAM, I had to ctrl-c at 92375. Does this look right? diff --git i/Src/parse.c w/Src/parse.c index 6e0856bbc1..ee1a1230ba 100644 --- i/Src/parse.c +++ w/Src/parse.c @@ -2742,7 +2742,7 @@ freeeprog(Eprog p) DPUTS(p->nref < 0 && !(p->flags & EF_HEAP), "Real EPROG has nref < 0"); DPUTS(p->nref < -1, "Uninitialised EPROG nref"); #ifdef MAX_FUNCTION_DEPTH - DPUTS(p->nref > MAX_FUNCTION_DEPTH + 10, "Overlarge EPROG nref"); + DPUTS(zsh_funcnest >= 0 && p->nref > zsh_funcnest + 10, "Overlarge EPROG nref"); #endif if (p->nref > 0 && !--p->nref) { for (i = p->npats, pp = p->pats; i--; pp++) -- Mikael Magnusson