From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12302 invoked by alias); 5 Jan 2014 17:58:54 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18282 Received: (qmail 27212 invoked from network); 5 Jan 2014 17:58:39 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=cOMHUalmdUseGcOw6yJSAvkLZdu3FuQ1o1ngqDj2Cjc=; b=k6B0I2hxLzte8F4GrPLVYWMCYgNtKTjzYQLDuJthjGcX9M3Q4ckWiQnhaV6z5q1rVA I8lCtmyMxyYWgRH+PY2h1RvjWcUFmquSglUYnDKIRKzgbALAvdsNO7BIzpD6n5cwPTqz Wj1HlDQfXN2ensxKa6QkMr23qaQ6MP0I6bJSoTX22ojHjy9i24qNKpzMb2eDRBDQVXun ooZ8WwrorqDh7oIlHT8l7NHLoB9KVVsv5awnZ2nUq5cPNrW6c2cIBPRj9Ob6YO5vhN3g Nh64YpDWf/FSAEyqPi2oQGPO9+it1jTdRVdnD21i/BoO0jMDWMZoBZlj+jHwMyTI3yJy ndsA== X-Gm-Message-State: ALoCoQn5QI+JRK2cL4n2CDIjHTlI6eMAJTZc9/UdgPTI1Y8Jk884/aDLC1N1uMHU/pTOYsExa6ht X-Received: by 10.180.184.105 with SMTP id et9mr9161470wic.36.1388944716182; Sun, 05 Jan 2014 09:58:36 -0800 (PST) X-ProxyUser-IP: 86.6.157.246 Date: Sun, 5 Jan 2014 17:58:31 +0000 From: Peter Stephenson To: zsh-users@zsh.org Subject: Re: Segmentation Fault on Stack Overflow Message-ID: <20140105175831.4640d8a5@pws-pc.ntlworld.com> In-Reply-To: <878uuwy0vk.fsf@ft.bewatermyfriend.org> References: <3540501074823477909@gmail297201516> <87d2k8y6wn.fsf@ft.bewatermyfriend.org> <878uuwy0vk.fsf@ft.bewatermyfriend.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 04 Jan 2014 02:46:55 +0100 Frank Terbeck wrote: > >> zsh% function inf() { inf }; inf > >> inf: maximum nested function level reached >=20 > Huh. I must be remembering something incorrectly. The limit was in place > since sometime in 2000=C2=B9. But you might be building with the > =E2=80=98--disable-max-function-depth=E2=80=99 configuration option. >=20 > Otherwise the limit should be in place (it defaults to 1000). If the > limit is in place, and the shell still crashes, it might be another > issue, which I couldn't reproduce then. The function depth limit is only a guess at the point where problems might occur. It depends on the local environment, both the physical configuration and the per-process limits, whether this is good enough. It might be possible to do a little better by querying some of the memory-related limits (I would guess available stack space is the key one, but some investigation will be necessary) to see if one of the limits is getting short and aborting function calls in a handlable fashion at that level. Unhelpfully, limits (from getrlimit()) and current usage (from getrusage()) don't seem to map cleanly onto one another, and this is all rather system-specific, so this doesn't look like a trivial project. pws