Re: out of memory error after "edit-command-line"

[Bart Schaefer <schaefer@brasslantern.com>]

On Fri, Aug 12, 2022 at 8:41 AM Jim <linux.tech.guy@gmail.com> wrote:
>
> Tried to isolate what causes the 'out of memory' errors and found that if
> I added quotes the error stopped.
>   CL=${(0A)"$(< /proc/$P/cmdline)"}  # OK
>   CL=${(0A)$(< /proc/$P/cmdline)}  # out of memory error

I didn't reproduce the out-of-memory error with zsh-5.9-31, but I did
reproduce an infinite loop in wordcount() because skipwsep() does not
consider a metafied NUL byte to be whitespace.  spacesplit() is
entered with e.g. 'zsh\203 -f\203 ' and calls wordcount() on the first
\203, which returns 2, then calls skipwsep() which returns without
skipping anything because iwsep(' '^32) is false, and around we go
again.

I think the OOM is related because spacesplit() will allocate memory
for each word that it believes it found, and the loop causes it to
keep finding empty words forever.  With sufficient RAM it just takes
so long to use it all up that I give up waiting and kill the shell
with gdb, which is how I found the loop case.

However, I can't come up with a minimal test case to invoke the
initial condition.  It's not enough just to do e.g.
${(0A)$(</proc/$$/cmdline)} in isolation.

Quotes matter because readoutput() does not call spacesplit() when
$(...) is quoted, but I don't know why extendedglob would make any
difference.

> But even so, should zsh ever fail with an 'out of memory' error?

There's really no way for the shell to know that it is imminently
going to run out of memory and no useful way to recover once it has
done so.  Except in cases of bugs (which this appears to be), OOM only
results from a programming error on the part of the user.

Back to the original problem ... it appears that findsep(&s, NULL, 0)
considers '\203 ' to be a separator (because a null byte is in $IFS ?)
but skipwsep() does not.  Can anyone else see why this doesn't break
in every case of splitting strings with embedded NUL ?