Re: segfault in mkundoent when completing

Re: segfault in mkundoent when completing

[Dirk-Jan C. Binnema]

On Monday Oct 26 2015, Bart Schaefer wrote:

> On Oct 25,  9:15pm, Dirk-Jan C. Binnema wrote:
> }
> } It seems to happen in all directories; I suspect it's something specific
> } to my configuration (when not using my ~/.zshrc, there's no crash),
> } though I don't think there's anything special there (and it worked fine
> } for years before the mentioned commit).
>
> Whether it "worked fine for years before" or not, probably the only way
> anyone else will be able to track this down is if you first narrow down
> the setting(s) from your .zshrc that must be in place in order to trigger
> the error.

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---

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: segfault in mkundoent when completing

[Peter Stephenson]

On Mon, 26 Oct 2015 09:18:50 +0200
Dirk-Jan C. Binnema <djcb@djcbsoftware.nl> 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;
 }