Re: Complex config triggering Segfault in pattern matching code.

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 13,  3:36pm, Jonathan H wrote:
}
} $ZSH_PATCHLEVEL == "zsh-5.0.7-0-g208bded"
} $(uname -a) == "Linux protogon.localdomain 3.17.6-1-ARCH #1 SMP
} PREEMPT Sun Dec 7 23:43:32 UTC 2014 x86_64 GNU/Linux"
} 
} I've attached the output of gdb backtrace, watch and the headers.

OK, thanks.  If you look closely at that backtrace, you'll see that the
shell is actually inside the zle-line-init widget, which means that the
entire editor is just starting up:

#364 "zle-line-init", arg=0x0) at zle_utils.c:1706

This calls through here:

#348 "auto-fu-init") at exec.c:5040
...
#332 "with-afu-zle-rebinding") at exec.c:5040
...
#314 "afu-line-init") at exec.c:5040
...
#301 "afu-recursive-edit-and-accept") at exec.c:5040
...
#290 "_zsh_highlight_widget_recursive-edit") at exec.c:5040
...
#280 recursiveedit (args=0x7fb1f7f4ba70) at zle_main.c:181


So at this point we haven't even finished initializing ZLE yet, but one of
these "auto-fu" functions has recursively invoked it.  This is a recipe for 
disaster if ever I saw one.  I suspect recursive-edit should simply throw
an error if it's invoked from zle-line-init, but PWS may be able to speak
better to this.

At this point we're already either hosed or about to be because ZLE isn't
ready to be re-entered yet within zle-line-init, but just to follow the
rest of the way:

#276 "self-insert-by-keymap") at exec.c:5040
...
#260 "afu+self-insert") at exec.c:5040
...
#252 "with-afu~") at exec.c:5040
...
#241 "with-afu-magic-insert~") at exec.c:5040
...
#233 "with-afu-magic-insert") at exec.c:5040
...
#220 "with-afu-resume") at exec.c:5040
...
#212 "with-afu-zsh-syntax-highlighting") at exec.c:5040

Oh-my-zsh syntax highlighting is known to tickle several subtle crash-
inducing memory errors, so if this function's name means anything, then
combined with the ill-timed recursive-edit this is most likely where
something gets scrambled and we're just waiting for the other shoe to
drop ... but on we go:

#199 "with-afu") at exec.c:5040
...
#186 "auto-fu-maybe") at exec.c:5040
...
#173 "with-afu-menuselecting-handling") at exec.c:5040
...
#165 "auto-fu") at exec.c:5040
...
#157 "with-afu-region-highlight-saving") at exec.c:5040
...
#144 "with-afu-completer-vars") at exec.c:5040
...
#136 "with-afu-compfuncs") at exec.c:5040
...
#126 completecall (args=0x7fb1f7f38918) at zle_tricky.c:208

So now we're in a recursive edit before ZLE has finished initialzing, and
completion is being invoked on something (I have no idea what at this point
because either the buffer is empty or one of those other auto-fu functions
stuffed something into it, probably with-afu-resume).

After this on down it's just ordinary completion, passing through your _cmd
function which tries every possible sort of completion one after the other
without checking whether the previous one found anything.  I don't know if
that's really what you meant for it to do.

Anyway, the location of the crash is just where the badly-freed or in some
other way abused chunk of memory, from some previous error, finally gets
re-used.  It's like shoulder pain during a heart attack; not the real
problem at all.

I hadn't seen auto-fu before but it appears to be a rewrite of the old
incremental-complete-word functions.  I'm mildly surprised to see that
it's using the keymap+widget technique, I didn't think anyone had even
noticed that existed.