Re: segmentation fault with {1..1234567}

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2014-07-05 09:57:03 -0700, Bart Schaefer wrote:
> 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.

No, I don't have any per-process limitation on the memory.

> } > 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.

No, it isn't, as there may remain plenty of memory. What sometimes
happens is that for some command, a malloc will be attempted on
several GB's. The failure is easy to detect, and one can go on
handling the failure in a normal way.

> 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.

NEVER use alloca to allocate a lot of memory. That's a well-known bug!

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)