Re: segmentation fault with {1..1234567}

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sun, 06 Jul 2014 09:16:09 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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 <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/