help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: linuxtechguy@gmail.com
Cc: devs <zsh-workers@zsh.org>
Subject: Re: out of memory error after "edit-command-line"
Date: Fri, 12 Aug 2022 13:18:22 -0700	[thread overview]
Message-ID: <CAH+w=7bBF+5vW_gQSuxAH8wqqJGztn+_y5rxG567c=NUcC+ohA@mail.gmail.com> (raw)
In-Reply-To: <CA+rB6GLESuh=VAybFCg9RrTJ-C2_wQ8XUc4G6OGaEyEX=QRw9A@mail.gmail.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

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

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

  reply	other threads:[~2022-08-12 20:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02  3:47 Jim
2022-08-12 15:33 ` Jim
2022-08-12 20:18   ` Bart Schaefer [this message]
2022-08-13  0:10     ` [PATCH] " Bart Schaefer
2022-10-18 15:07       ` [PATCH] " Jun. T
2022-10-18 20:08         ` Bart Schaefer
2022-10-19  9:12         ` Jun T
2022-10-27  5:34           ` Jun T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7bBF+5vW_gQSuxAH8wqqJGztn+_y5rxG567c=NUcC+ohA@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=linuxtechguy@gmail.com \
    --cc=zsh-workers@zsh.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).