Re: segfault via completion menu

[Oliver Kiddle <okiddle@yahoo.co.uk>]

On 9 Apr, Wesley Schwengle wrote:
> today I've experiences a segfault running on an update to date zsh
> from git (6f35d6c0d0eeb80c0145e5226285a8a45ffb5f25)

Thanks for sending this to us.

> I can trigger this in a fairly "large" git repo such as the one I have
> at work, or using the repository of git itself. I've included the
> output of gdb
>
> I can trigger the bug with zsh -f and the attached zshrc:
>
> * cd ~code/git # the git repo from git@github.com:git/git.git
> * zsh -f
> * source the zshrc provided in this e-mail
> * vi Zaaksysteem::Bar::voo::vooo::voo<tab> <nowwaitafewsecs> <ctrl-c>
> * You now get a message: Killed by signal in compadd after 0s
> * vi <tab> # yields a segfault

This seems to be due to interrupting of pattern matching. I was able to
cut this down to something that doesn't involve completion:

  zsh -f
  setopt extendedglob
  () {
    TRAPINT() {
      return 1
    }
    : **/*~(#a10)Zaaksysteem::Bar::voo::vooo::voo
  }

  interrupt the function with Ctrl-C and now do something that involves
  pattern matching, e.g:

  [[ a = :*: ]]

The glob can be varied, it just needs to take long enough to give you
time to catch it with Ctrl-C so pick a big enough directory.

Older versions of zsh didn't have the problem so I've been able to
bisect it down to the change that introduced it:

[827d36077641ca87d1796b9c5cb05e7c44b01919] 36853: replace pushheap/popheap by NEWHEAPS/OLDHEAPS in doshfunc() to optimize memory management

Backing that out on top of master appears to fix the issue. As it was an
optimisation, that might be an option. From reading comments in mem.c,
it's not especially clear to me what newheaps/oldheaps do. There's only
the one other use.

Oliver