From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2258 invoked by alias); 6 Jul 2014 18:36: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: 32845 Received: (qmail 27210 invoked from network); 6 Jul 2014 18:36:32 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Originating-IP: [86.6.157.246] X-Spam: 0 X-Authority: v=2.1 cv=XPS+SGRE c=1 sm=1 tr=0 a=BvYiZ/UW0Fmn8Wufq9dPrg==:117 a=BvYiZ/UW0Fmn8Wufq9dPrg==:17 a=NLZqzBF-AAAA:8 a=yo2zJndj9JIA:10 a=uObrxnre4hsA:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=JKTtzv4YjNe0L-LnvIIA:9 a=CjuIK1q_8ugA:10 a=I6wTmPyJxzYA:10 a=_dQi-Dcv4p4A:10 Date: Sun, 6 Jul 2014 19:30:55 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: segmentation fault with {1..1234567} Message-ID: <20140706193055.209f7a2b@pws-pc.ntlworld.com> In-Reply-To: <140706091609.ZM18865@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> 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=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 06 Jul 2014 09:16:09 -0700 Bart Schaefer wrote: > In any case I'm not in a position to continue debating this. Zsh treats > out of memory as a fatal error at nearly the lowest levels of its memory > management and that's not changing without some major rewriting. This is generally true, but it's not quite the problem in this case. Here we don't actually need to be out of memory if we allocate it appropriately. > } NEVER use alloca to allocate a lot of memory. That's a well-known bug! > > 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. diff --git a/Src/builtin.c b/Src/builtin.c index 42354b9..3af5fb9 100644 --- a/Src/builtin.c +++ b/Src/builtin.c @@ -280,8 +280,8 @@ execbuiltin(LinkList args, Builtin bn) * after option processing, but it makes XTRACE output * much simpler. */ - VARARR(char *, argarr, argc + 1); char **argv; + char **argarr = zhalloc((argc + 1)*sizeof(char *)); /* * Get the actual arguments, into argv. Remember argarr -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/