Re: BUG: Zsh crashes

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Sat, 14 Jan 2017 02:48:33 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> More minimal reproducer:
> 
> % git clone --depth 5 gitn://github.com/robbyrussell/oh-my-zsh.git
> % mkdir d
> % cp */plugins/rust/_rust d 
> % fpath+=($PWD/d) 
> % autoload compinit
> % compinit 
> % rustc --pretty flowgraph==<TAB><TAB>
> 
> This uses the _rust from omz but nothing else from it.

Excellent, just what we need, thanks.

With ZSH_SECURE_FREE this goes wrong with the error message at line 1506
of mem.c.  That comes from a bad free of a parameter.  I'm guessing this
is (a) earlier than the crash, obviously (b) already somewhat later than
the fundamental problem, which is presumably memory related.

Interestingly, even with exactly the same steps I've seen two slightly
different versions:

- the free came from scanendscope for function _normal
- the free came from deleting a hashtable associated with _lastcomp.

and within those the symptoms aren't stable, either.

In both cases it's from a parameter, but it doesn't look like it's a
single particular erroneous parameter that's the problem; I suspect the
original error has come much earlier.  The relationship to the hash
table of a hash parameter could well be just because that has a
particular large memory footprint for the problem to hit.

Normal valgrind didn't show anything helfupl.  Valgrind integration with
heaps with --enble-zsh-valgrind hasn't been working properly for a while
now, but the circumstantial evidence points more to permanent allocation
problem anyway.

The fact that it's the second tab must be relevant in some way.  Some
state may not be being preserved properly.

This is going to take some lateral thinking.  Anyone who can think
laterally might be able to help.  Playing with the completer, for
example.

pws