From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22943 invoked by alias); 26 Oct 2015 09:55:24 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20825 Received: (qmail 12778 invoked from network); 26 Oct 2015 09:55:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Originating-IP: [86.6.158.222] X-Spam: 0 X-Authority: v=2.1 cv=TNS4MARa c=1 sm=1 tr=0 a=2SBOh4l1h08DI0L+aujZyQ==:117 a=2SBOh4l1h08DI0L+aujZyQ==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=5mU5rViTnTrLdjV6DGoA:9 a=CjuIK1q_8ugA:10 Date: Mon, 26 Oct 2015 09:49:41 +0000 From: Peter Stephenson To: "Dirk-Jan C. Binnema" Cc: zsh-users@zsh.org Subject: Re: segfault in mkundoent when completing Message-ID: <20151026094941.7354c721@ntlworld.com> In-Reply-To: <87fv0ym71h.fsf@djcbsoftware.nl> References: <874mhfe8ng.fsf@djcbsoftware.nl> <151025095136.ZM29675@torch.brasslantern.com> <87y4eqahet.fsf@djcbsoftware.nl> <151025180706.ZM30568@torch.brasslantern.com> <87fv0ym71h.fsf@djcbsoftware.nl> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 26 Oct 2015 09:18:50 +0200 Dirk-Jan C. Binnema wrote: > Hmmm, it seems some kind of interaction between a few different things; > but I was amble to reproduce it with this ~/.zshrc (using the external > highlighting package): > > --8<---------------cut here---------------start------------->8--- > setopt allexport > autoload -U compinit > compinit > source ~/Sources/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh > --8<---------------cut here---------------end--------------->8--- Yes, this is showing it's... > Hmm... the change in question adds mkundoent() in a different context. > I'm wondering if that UNMETACHECK() just above the crash might go off if > this were copmiled with --enable-zsh-debug. But I couldn't get this to > happen easily myself, even adding an extra DPUTS(). I presume there are now a few extra hooks around causing it to happen in completion context. The easiest thing is to add protection we've already get in handleundo(), which I've just copied verbatim. pws diff --git a/Src/Zle/zle_utils.c b/Src/Zle/zle_utils.c index 714d911..ffff8fd 100644 --- a/Src/Zle/zle_utils.c +++ b/Src/Zle/zle_utils.c @@ -1739,9 +1739,26 @@ zlecallhook(char *name, char *arg) zlong get_undo_current_change(UNUSED(Param pm)) { + int remetafy; + + /* + * Yuk: we call this from within the completion system, + * so we need to convert back to the form which can be + * copied into undo entries. + */ + if (zlemetaline != NULL) { + unmetafy_line(); + remetafy = 1; + } else + remetafy = 0; + /* add entry for any pending changes */ mkundoent(); setlastline(); + + if (remetafy) + metafy_line(); + return undo_changeno; }