Re: segmentation fault with {1..1234567}

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jul 6,  1:39am, Vincent Lefevre wrote:
} Subject: Re: segmentation fault with {1..1234567}
}
} On 2014-07-05 09:57:03 -0700, Bart Schaefer wrote:
} > 
} > Then it's probably a per-process resource limit problem.
} 
} No, I don't have any per-process limitation on the memory.

Apparently, though, you may have one on stack space.

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

"Sometimes."

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.

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

All tests still pass when VARARR() is redefined to use zhalloc(), so it
should be straightforward to add a configure switch for this, if we can
decide what to call it and what its default setting should be.  However,
I didn't check with valgrind to see if memory is left unfreed in this
circumstance; we may need additional heap management calls as well.