From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17530 invoked by alias); 14 Dec 2014 04:40:19 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33962 Received: (qmail 17345 invoked from network); 14 Dec 2014 04:40:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=B94OC1pJ c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=A92cGCtB03wA:10 a=CPd1014Amn-RgO2-uroA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141213204032.ZM16766@torch.brasslantern.com> Date: Sat, 13 Dec 2014 20:40:32 -0800 In-reply-to: Comments: In reply to Jonathan H "Re: Complex config triggering Segfault in pattern matching code." (Dec 13, 3:36pm) References: <141213152840.ZM16632@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Jonathan H , zsh-workers@zsh.org Subject: Re: Complex config triggering Segfault in pattern matching code. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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.