* Peter Stephenson <1514882387.357077.1640002234148@mail2.virginmedia.com> :
Wrote on Mon, 20 Dec 2021 12:10:34 +0000 (GMT):

> On 12/20/21, Mikael Magnusson <mikachu@gmail.com> wrote:
>> On 4/26/08, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>>> - if (replstr) { + if (replstr || (fl & SUB_LIST)) {
>> Someone in the irc channel reported a crash on this strlen when
>> doing history-incremental-pattern-search-backward with any search,
>> and they can reproduce it with the latest git version too, they
>> posted this backtrace:
>
> That extra test doesn't look like it makes any sense --- I think it
> may just be in completely the wrong place and shouldn't be in
> get_match_ret() at all since it's similar to some checks in other
> places where we allow zero-length (but not NULL) strings for some edge
> cases in some variants of matching.  We should probably just remove it
> and see what happens.
>
> pws
>
> diff --git a/Src/glob.c b/Src/glob.c index bee890caf..375671cea 100644
> --- a/Src/glob.c +++ b/Src/glob.c @@ -2549,7 +2549,7 @@
> get_match_ret(Imatchdata imd, int b, int e) e += add;
>      /* Everything now refers to metafied lengths. */ - if (replstr ||
> (fl & SUB_LIST)) { + if (replstr) { if (fl & SUB_DOSUBST) { replstr =
> dupstring(replstr); singsub(&replstr);

This doesn't fix the segfault: which just gets postponed.  Besides
this breaks incremental-pattern-search, which just stops working and
doesn't match anything in the history. Also, the segfault only occurs
when zsh is built without multibyte.

To hit the segfault, in a --disable-multibyte build
$ zsh -f
$ bindkey ^R history-incremental-pattern-search-backward
C-r .

Please consider the attached patch which 1) reverts the above fix, and
2) modifies the non-multibyte version of igetmatch to match the
multibyte version at some points. (Disclaimer. this is submitted with
no understanding of what the code does :)