Re: [PATCH] Fix zsh goes infinite loop running completion

[Heon Jeong <blmarket@xxxxxxxxx>]

Seems locale really matters. I guess locale affects how metafy behaves
which is critical for the bug.

* Bug happens: en_US.UTF-8, en_CA.UTF-8
* Not reproducible: ko_KR.UTF-8, C.UTF-8

Also I found the fix is incorrect as the behavior is different than
other locales. I'm happy to rework the fix, but first it would be
great if someone can verify the bug is reproducible.

2025년 10월 19일 (일) 오전 8:16, Heon Jeong <blmarket@xxxxxxxxx>님이 작성:
>
> Thanks for the smaller environment setup. I was able to reproduce the
> bug with it. (assuming some newlines in the mail was space)
>
> 1. Can you check the locale? The bug happens only if multibyte
> encoding is enabled (see Dockerfile - may need to create and use some
> UTF-8 locale such as en_US.UTF-8)
> 2. I tested in following env:
> - Arch linux x86-64, zsh 5.9 (x86_64-pc-linux-gnu)
> - Docker: Debian x86-64, zsh 5.9.0.3-test (x86_64-pc-linux-gnu)
> - NixOS arm64, zsh 5.9 (aarch64-unknown-linux-gnu)
>
>
> 2025년 10월 19일 (일) 오전 5:12, Mikael Magnusson <mikachu@xxxxxxxxx>님이 작성:
> >
> > On Sun, Oct 19, 2025 at 8:08 AM Heon Jeong <blmarket@xxxxxxxxx> wrote:
> > >
> > > sub_match can return a negative number in a very rare condition, which
> > > can cause zsh to hang and consume 100% cpu + ever increasing memory.
> > >
> > > Minimal reproduction env: https://github.com/blmarket/zsh-bug
> > >
> > > Usage: clone the repo, create docker/podman container with Dockerfile
> > > run the container, get into /env, run ./build, run ./run, type `rm
> > > E01` then tab tab -> hang
> > >
> > > When the filename is utf-8 with a certain condition, its multibyte
> > > handling can get the last 1 byte prefixed in the search string, which
> > > is captured by the sub_match function. the caller(join_psfx) get -1 as
> > > a result which causes the function to go into an infinite loop.
> > >
> > > I also observed memory consumption keep increasing during the hang,
> > > but didn't debug why.
> > >
> > > Proposed fix is to make sure sub_match does not to return ne
> > > gative value.
> > >
> > > diff --git a/Src/Zle/compmatch.c b/Src/Zle/compmatch.c
> > > index b58bd1f05..11de6ef51 100644
> > > --- a/Src/Zle/compmatch.c
> > > +++ b/Src/Zle/compmatch.c
> > > @@ -2424,6 +2424,8 @@ sub_match(Cmdata md, char *str, int len, int sfx)
> > >                 md->str += l; str += l;
> > >             }
> > >             ret += l;
> > > +           if (ret < 0)
> > > +               ret = 0;
> > >         } else if (md->line || md->len != md->olen || !md->astr)
> > >             return ret;
> > >         else {
> > >
> >
> > I tried these steps on current git zsh and couldn't reproduce a
> > problem, nor with older binaries of zsh:
> > % touch "A-개미허리 간다.E01.251009.108-F.mp4" "상어개인4.첫
> > 방송.E01.251014.1080p.H264-ASDFNEWS.mp4" build run
> > % zsh -f
> > % autoload -U compinit; compinit; zstyle ':completion:*' matcher-list
> > 'm:{[:lower:][:upper:]}={[:upper:][:lower:]}' 'r:|=*' 'l:|=* r:|=*';
> > zstyle ':completion:*' special-dirs true
> > % rm E01<tab>
> > % rm .E01.2510 #resulting commandline from completion
> >
> > --
> > Mikael Magnusson