Re: Complex config triggering Segfault in pattern matching code.

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

On Sat, 13 Dec 2014 20:40:32 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> 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:
>...
> #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.

I'm not actually what would go wrong here.

After zle-line-init runs (in zleread),the next thing we do is zrefresh()
and then zlecore().  So I think it *has* finished initialising ---
zrefresh() and zlecore() are the stuff that we can only do when zsh is
set up and we can do them at this point.

Indeed, zlecore() is basically what recursive-edit does, although
there's quite lot in the way in the hook stuff in execzlefunc().  So if
something's going wrong here it's the hooking rather than the not being
started that should prevent a recursive edit.  But I still don't know
what it is we can't allow because of what.

> 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

I don't actually see why not, as I said above.

> Oh-my-zsh syntax highlighting is known to tickle several subtle crash-
> inducing memory errors

This is probably more to the point.

> #126 completecall (args=0x7fb1f7f38918) at zle_tricky.c:208

This is utterly bizarre, but, again, I'm not really sure what the core
shell should be disallowing.  It's up to the user rather than the shell
not to complete anything before they've even started up the command
line...

> 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.

Would it be possible to run valgrind on this, if it's sufficiently
reproducible?

pws