From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13228 invoked by alias); 6 Jul 2014 22:23:37 -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: 32850 Received: (qmail 11225 invoked from network); 6 Jul 2014 22:23:34 -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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PfopOLJ0oIvmeCbTt79jNAfRiy3gpaQzFbRqnSmKLIg=; b=gizUghOvXZS8NLTiRdDmJxbuHfcL6/2ydWA5H6i2iPeVQUH0ZQQoXcP+OBrBeVmeVI u5PdB43HE4Cb0F1921dElRP0GJmcJm8P7XnfyTzCTFtmxcIJCa18a2jFBHnmbnf7sYYS t6R/ZCGIbGs6oSD0wYG1IoIWyBPvfh2GYB2YAduMtoIYZ6GQscELfPABUPnfTqcKZzaE mGlCwvZhi2B0x4+tkykVe6GKCATisjusEJG5cPdV7wElxVAz6gcqI2CALopddpNDQK7t EYIj9BUegOidW41Q6J5kvuYftDuMio0P6LlxrsWrT4aVdO19l/r5nLRWMECRlm3fYg06 xHuw== MIME-Version: 1.0 X-Received: by 10.224.115.3 with SMTP id g3mr42491894qaq.9.1404685411362; Sun, 06 Jul 2014 15:23:31 -0700 (PDT) In-Reply-To: <140706124629.ZM19578@torch.brasslantern.com> References: <20140704172545.GA29213@xvii.vinc17.org> <140704184036.ZM18558@torch.brasslantern.com> <20140705111233.GA19385@xvii.vinc17.org> <140705095703.ZM12012@torch.brasslantern.com> <20140705233916.GA18368@xvii.vinc17.org> <140706091609.ZM18865@torch.brasslantern.com> <20140706193055.209f7a2b@pws-pc.ntlworld.com> <140706124629.ZM19578@torch.brasslantern.com> Date: Mon, 7 Jul 2014 00:23:31 +0200 Message-ID: Subject: Re: segmentation fault with {1..1234567} From: Mikael Magnusson To: Bart Schaefer Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On 6 July 2014 21:46, Bart Schaefer wrote: > On Jul 6, 7:30pm, Peter Stephenson wrote: > } Subject: Re: segmentation fault with {1..1234567} > } > } On Sun, 06 Jul 2014 09:16:09 -0700 > } Bart Schaefer wrote: > } > IIRC the use of VARARR() was introduced in order to more evenly split the > } > memory use between the heap and the stack on systems that had limited RAM. > } > Obviously more recent hardware is likely to have divided process address > } > space differently, and this former optimization has become a liability. > } > } Well, all I can say is that without the following change it crashes on > } my system (where I have not tweaked any limits) and with the following > } change it doesn't. > } > } Maybe I'm just selfish but I prefer the latter. > > I do not disagree. > > The question is, do we fix this one instance (your patch), do we redefine > VARARR() [possibly conditionally] to change all the usages at once, or do > we individually evaluate the 50-odd uses of VARARR()? > > What constitutes "a lot" to avoid using alloca() upon? I believe the default stack size on linux is 8MB per thread, at least it is on my system. Setting ulimit -s 65535 makes the original command work for me while by default it crashes. -- Mikael Magnusson