From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7962 invoked by alias); 5 Jul 2014 16:57:42 -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: 32841 Received: (qmail 4262 invoked from network); 5 Jul 2014 16:57:29 -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: <140705095703.ZM12012@torch.brasslantern.com> Date: Sat, 05 Jul 2014 09:57:03 -0700 In-reply-to: <20140705111233.GA19385@xvii.vinc17.org> Comments: In reply to Vincent Lefevre "Re: segmentation fault with {1..1234567}" (Jul 5, 1:12pm) References: <20140704172545.GA29213@xvii.vinc17.org> <140704184036.ZM18558@torch.brasslantern.com> <20140705111233.GA19385@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 5, 1:12pm, Vincent Lefevre wrote: } } > Whether that expression fails depends entirely on the memory allocation } > limitations of the local host. It works fine for me. } } That's not a memory allocation problem: it fails on a machine } with 24GB! Then it's probably a per-process resource limit problem. } > What's the "expected" behavior of the shell when the user requests a } > vast amount of memory? How should the shell recover from running out of } > memory at any arbitrary point during execution of a command or script? } > Is it really helpful to trap the signal and exit *without* dumping core? } } No, the signal means that it is already too late. Running out of memory at all means it's already too late, is my point. There's no way to know what allocated memory can be unwound/reclaimed, so even if you discover that e.g. malloc() has returned zero there is (in the general case) no safe way to report the error and return to a prompt without ending up in a state where every action at that prompt uselessly reports the same error again. Anyway, that's not [directly] the problem here. In this particular case the shell is running out of memory on the stack, attempting to declare a variable length array via the VARARR() macro. There is no well-defined way to recover from that, e.g., "man 3 alloca": RETURN VALUE The alloca function returns a pointer to the beginning of the allocated space. If the allocation causes stack overflow, program behaviour is undefined.