Re: PATCH: 3.1.6-pws-6: $compstate[unambiguous] could be garbage

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Oct 7,  1:30pm, Clint Adams wrote:
> Subject: Re: PATCH: 3.1.6-pws-6: $compstate[unambiguous] could be garbage
> > -    } else {
> > +    } else if (mnum != unambig_mnum || !ainfo || !scache) {
> 
> Still getting things like
> 
> _main_complete: bad pattern: x['^H8T^V@ [92]

Well, that certainly does appear that it could be caused by this or a
similar problem.  `unambiguous' and `unambiguous_cursor' are the only keys
that have readonly computed values, and as it turns out they're both
computed by the same caching function, which is what caused the bug I saw
in the first place.

So if you get a debugger going and put a breakpoint in unambig_data() and
manage to see it free and reallocate the `scache' pointer twice, let us
know what `mnum', `unambig_mnum', and `ainfo' were when it happened.

One thing I tried while figuring out what was going on for the patch above
was inserting

noglob print -l x"${(@kv)^compstate}"x

immediately before line 92.  That would at least tell you which assoc key
has the bad value.