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@xxxxxxxxxxxx> wrote: > On Sat, 13 Dec 2014 20:40:32 -0800 > Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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
Attachment:
zsh_valgrind.log
Description: Binary data