Re: segmentation fault with {1..1234567}

[Mikael Magnusson <mikachu@gmail.com>]

On 6 July 2014 21:46, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jul 6,  7:30pm, Peter Stephenson wrote:
> } Subject: Re: segmentation fault with {1..1234567}
> }
> } On Sun, 06 Jul 2014 09:16:09 -0700
> } Bart Schaefer <schaefer@brasslantern.com> wrote:
> } > 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.
>
> I do not disagree.
>
> The question is, do we fix this one instance (your patch), do we redefine
> VARARR() [possibly conditionally] to change all the usages at once, or do
> we individually evaluate the 50-odd uses of VARARR()?
>
> What constitutes "a lot" to avoid using alloca() upon?

I believe the default stack size on linux is 8MB per thread, at least
it is on my system. Setting ulimit -s 65535 makes the original command
work for me while by default it crashes.

-- 
Mikael Magnusson