From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14601 invoked by alias); 8 Jul 2014 10:48:59 -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: 32855 Received: (qmail 7753 invoked from network); 8 Jul 2014 10:48:57 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7fac6d000006cfe-94-53bbca3351c3 Date: Tue, 08 Jul 2014 11:38:42 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: segmentation fault with {1..1234567} Message-id: <20140708113842.77378f62@pwslap01u.europe.root.pri> In-reply-to: <140707180806.ZM20805@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> <20140707203312.27566ab8@pws-pc.ntlworld.com> <140707180806.ZM20805@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42I5/e/4NV3jU7uDDa4eFrU42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGYueTmYv+MNRce7/BsYGxmnsXYycHBICJhJLtl9hg7DFJC7c Ww9kc3EICSxllJh3cyIjhLOcSeLElAdAGQ4OFgFViamv4kAa2AQMJaZums0IYosIiEucXXue BcQWBorffP0QbCivgL1E7+yNjCCtnAJWEvvf80GMvMUs8XbSUbAafgF9iat/PzFBHGEvMfPK GUaIXkGJH5Pvgc1kFtCS2LytiRXClpfYvOYt8wRGgVlIymYhKZuFpGwBI/MqRtHU0uSC4qT0 XEO94sTc4tK8dL3k/NxNjJAQ/LKDcfExq0OMAhyMSjy8GrW7g4VYE8uKK3MPMUpwMCuJ8Oat AArxpiRWVqUW5ccXleakFh9iZOLglGpgzP6Tress1KF0eJGpYCTzFp85f7WF1IPF3R96l8Q9 OVlk13juRpbYjWmf/8qVfjiaXlpqN41JmSusdE74v2ZZXS1dLuniK4qWj+7rcv+ezZt34NNr vgO26UJnBNI4bgc6reO4lXrSlcHr+Mz5Wb2lbMEVt3e2rl/DfVL9uVHGx6WtBVOErz5RYinO SDTUYi4qTgQAeC3+2h8CAAA= On Mon, 07 Jul 2014 18:08:06 -0700 Bart Schaefer wrote: > On Jul 7, 8:33pm, Peter Stephenson wrote: > } Subject: Re: segmentation fault with {1..1234567} > } > } On Sun, 06 Jul 2014 12:46:29 -0700 > } Bart Schaefer wrote: > } > The question is ... do we redefine > } > VARARR() [possibly conditionally] to change all the usages at once ...? > > Well, that one is easy, as I mentioned earlier; see patch below. One added > hunk in mem.c for a place where we didn't check the return of malloc, but I > did not attempt to change the usual fatal-error behavior. I'm trying this out, but I'm not sure I'm likely to prod the most likely problem areas with my usage. I guess that would be things that can allocate large chunks repeatedly before there's a popheap() or a freeheap(). We've previously fixed this up for syntactic loops, i.e. while, for, repeat, but there may be relevant internal loops. Most if not all of the allocations are individually amenable to turning into malloc and free if it turns out to be the easiest option following experimentation. pws