From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18716 invoked by alias); 6 Jul 2014 16:16:08 -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: 32844 Received: (qmail 19962 invoked from network); 6 Jul 2014 16:16:04 -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 From: Bart Schaefer Message-id: <140706091609.ZM18865@torch.brasslantern.com> Date: Sun, 06 Jul 2014 09:16:09 -0700 In-reply-to: <20140705233916.GA18368@xvii.vinc17.org> Comments: In reply to Vincent Lefevre "Re: segmentation fault with {1..1234567}" (Jul 6, 1:39am) 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> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: segmentation fault with {1..1234567} MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jul 6, 1:39am, Vincent Lefevre wrote: } Subject: Re: segmentation fault with {1..1234567} } } On 2014-07-05 09:57:03 -0700, Bart Schaefer wrote: } > } > Then it's probably a per-process resource limit problem. } } No, I don't have any per-process limitation on the memory. Apparently, though, you may have one on stack space. } > Running out of memory at all means it's already too late, is my point. } } No, it isn't, as there may remain plenty of memory. What sometimes } happens is "Sometimes." 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. } 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. All tests still pass when VARARR() is redefined to use zhalloc(), so it should be straightforward to add a configure switch for this, if we can decide what to call it and what its default setting should be. However, I didn't check with valgrind to see if memory is left unfreed in this circumstance; we may need additional heap management calls as well.