Re: segmentation fault with {1..1234567}

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.