zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: linuxtechguy@gmail.com
Cc: devs <zsh-workers@zsh.org>
Subject: [PATCH] Re: out of memory error after "edit-command-line"
Date: Fri, 12 Aug 2022 17:10:39 -0700	[thread overview]
Message-ID: <CAH+w=7briYScsSHJs9Hz-H+t3QXvZ8mBEe_XZVmD2FoNZZiraQ@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7bBF+5vW_gQSuxAH8wqqJGztn+_y5rxG567c=NUcC+ohA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On Fri, Aug 12, 2022 at 1:18 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> 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.
> [...] it appears that findsep(&s, NULL, 0)
> considers '\203 ' to be a separator (because a null byte is in $IFS ?)
> but skipwsep() does not.

OK, that's a red herring.  The real problem is that itype_end(s, ISEP,
1) is not skipping over the '\203 ' pair in Jim's example, whereas it
does in the simple example above.

Once this becomes broken, it remains broken -- the simple example
starts infinite-looping as well.

It seems to come down to this in itype_end():
4359                case ISEP:
4360                if (!wmemchr(ifs_wide.chars, wc, ifs_wide.len))
4361                    return (char *)ptr;

On entry to that case in the simple example, wmemchr() returns nonzero
for wc == 0.  After edit-command-line, wmemchr() starts returning zero
in that case.  It appears ifs_wide has been erased.

The problem starts here in edit-command-line:

  # Compute the cursor's position in bytes, not characters.
  setopt localoptions nomultibyte noksharrays

When nomultibyte is set, inittyptab() is called and erases ifs_wide.
This is not restored when emulation mode ends and multibyte is
re-asserted.

The following patch fixes this example, but might only be a partial
fix for problems with locally flipping the state of various options
(MONITOR, BANGHIST, SHINSTDIN come to mind).  I think really we should
be looping over the options and calling dosetopt() for each one
instead of just memcpy'ing the saved set back on top of the original
... or at least we need a mapping of the subset of options that have
extra code associated with a change via setopt.

[-- Attachment #2: localnomultibyte.txt --]
[-- Type: text/plain, Size: 790 bytes --]

diff --git a/Src/exec.c b/Src/exec.c
index f2911807c..77763f536 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -5962,10 +5962,17 @@ doshfunc(Shfunc shfunc, LinkList doshargs, int noreturnval)
 	    sticky = funcsave->sticky;
 	} else if (isset(LOCALOPTIONS)) {
 	    /* restore all shell options except PRIVILEGED and RESTRICTED */
+#ifdef MULTIBYTE_SUPPORT
+	    int flip_multibyte = opts[MULTIBYTE];
+#endif
 	    funcsave->opts[PRIVILEGED] = opts[PRIVILEGED];
 	    funcsave->opts[RESTRICTED] = opts[RESTRICTED];
 	    memcpy(opts, funcsave->opts, sizeof(opts));
 	    emulation = funcsave->emulation;
+#ifdef MULTIBYTE_SUPPORT
+	    if (flip_multibyte != opts[MULTIBYTE])
+		inittyptab();
+#endif
 	} else {
 	    /* just restore a couple. */
 	    opts[XTRACE] = funcsave->opts[XTRACE];


  reply	other threads:[~2022-08-13  0:21 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
2022-08-13  0:10     ` Bart Schaefer [this message]
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:
  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=7briYScsSHJs9Hz-H+t3QXvZ8mBEe_XZVmD2FoNZZiraQ@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=linuxtechguy@gmail.com \
    --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).