It usually is, but for some reason I can't get it to crash in
valgrind. I forgot to tell you guys, but the crashes happen more often
when the user types rapidly. (Race condition related maybe).

Anyway, here's the STDERR from "valgrind -v -v". It shows some errors
or something so maybe it's still of use. I'll post if I can get it to
crash though.



On Sun, Dec 14, 2014 at 10:20 AM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> 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