From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24933 invoked by alias); 14 Dec 2014 18:20:33 -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: 33965 Received: (qmail 6331 invoked from network); 14 Dec 2014 18:20:28 -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-Originating-IP: [86.6.25.230] X-Spam: 0 X-Authority: v=2.1 cv=dY0O3Bne c=1 sm=1 tr=0 a=c0CwWhpM9oUd/BnC3z6Gzg==:117 a=c0CwWhpM9oUd/BnC3z6Gzg==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=7Oazl217M6edRdlnIjMA:9 a=CjuIK1q_8ugA:10 Date: Sun, 14 Dec 2014 18:20:21 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Cc: Jonathan H Subject: Re: Complex config triggering Segfault in pattern matching code. Message-ID: <20141214182021.1944bbcd@pws-pc.ntlworld.com> In-Reply-To: <141213204032.ZM16766@torch.brasslantern.com> References: <141213152840.ZM16632@torch.brasslantern.com> <141213204032.ZM16766@torch.brasslantern.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 13 Dec 2014 20:40:32 -0800 Bart Schaefer 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