zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Jun T <takimoto-j@kba.biglobe.ne.jp>
Cc: zsh-workers@zsh.org
Subject: Re: ZSH crashed when reading bytes from a large binary
Date: Wed, 14 Sep 2022 14:43:40 -0700	[thread overview]
Message-ID: <CAH+w=7ZgOzi1uPrCC8gzoGH86K3+z1-O-+1WtfnxFPjwdhNd6A@mail.gmail.com> (raw)
In-Reply-To: <8F410818-257D-470A-B620-2F776E960ABC@kba.biglobe.ne.jp>

On Mon, Sep 12, 2022 at 12:37 AM Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> > 2022/09/11 23:43, Liu, Song <songliu@psu.edu> wrote:
> >
> > The problem is that, when ZSH failed to reallocate memory, ZSH didn’t check the return value of `realloc` function and handle the error. This will make ZSH crash.
>
> There are many other places where the return value of realloc() is not checked.
> Can we simply replace them by zrealloc()?

Replacing them with zrealloc() will still result in immediate exit of
the shell, just with a different error message and no stack trace.

> > } else {
> > free(buf);
> > return EXIT_FAILURE;
> > }

The specific question here is whether having the "read" builtin return
failure at this point will allow the shell to recover from the
out-of-memory state, or whether it's just delaying the inevitable
death.  (Aside, we use EXIT_FAILURE exactly nowhere, so if we do not
exit, this should just be "return 1" as if end-of-file was encountered
per docs.)

In most cases we've assumed that once the shell is out of memory,
there's no way back, so how it dies is not that interesting.


  reply	other threads:[~2022-09-14 21:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-11 14:43 Liu, Song
2022-09-12  7:36 ` Jun T
2022-09-14 21:43   ` Bart Schaefer [this message]
2022-09-15 10:19     ` Jun T
2022-09-15 10:41       ` Peter Stephenson

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAH+w=7ZgOzi1uPrCC8gzoGH86K3+z1-O-+1WtfnxFPjwdhNd6A@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=takimoto-j@kba.biglobe.ne.jp \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.vuxu.org/mirror/zsh/

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