compctl crash

compctl crash

[Nicholas Riley]

I misunderstood the documentation for compctl, so I tried this:

compctl +

This crashes zsh back to at least 4.3.9 and up to the current version in 
Git.  I had thought it would reset all the compctl-defined completions.

glibc logs something of the form:

*** glibc detected *** zsh: double free or corruption (!prev): 
0x09b89ca8 ***
-- 
Nicholas Riley <njriley@illinois.edu>

Re: compctl crash

[Frank Terbeck]

Nicholas Riley wrote:
> I misunderstood the documentation for compctl, so I tried this:
>
> compctl +
>
> This crashes zsh back to at least 4.3.9 and up to the current version in 
> Git.

I tried 4.3.10 and a git build that's a few days old, but I could not
reproduce the problem.

> I had thought it would reset all the compctl-defined completions.

Note, that compctl is the older of the two completion systems, that zsh
implements. The newer - compsys - is the one almost everybody uses
(unless they still get that trusty old i386SX-16 another go every once
in a while...).

> glibc logs something of the form:
>
> *** glibc detected *** zsh: double free or corruption (!prev): 
> 0x09b89ca8 ***

Do you get a coredump? If so, could you load it into gdb and get a
backtrace?

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: compctl crash

[Nicholas Riley]

In article <87obdb786z.fsf@ft.bewatermyfriend.org>,
 Frank Terbeck <ft@bewatermyfriend.org> wrote:

> I tried 4.3.10 and a git build that's a few days old, but I could not
> reproduce the problem.

Sorry, given I tried it on two different OSes and wildly differing 
versions I assumed it would be trivial to reproduce.

> > I had thought it would reset all the compctl-defined completions.
> 
> Note, that compctl is the older of the two completion systems, that zsh
> implements. The newer - compsys - is the one almost everybody uses
> (unless they still get that trusty old i386SX-16 another go every once
> in a while...).

Yeah, the only reason I'm even bothering is in my other email - because 
virtualenvwrapper uses it.

> > glibc logs something of the form:
> >
> > *** glibc detected *** zsh: double free or corruption (!prev): 
> > 0x09b89ca8 ***
> 
> Do you get a coredump? If so, could you load it into gdb and get a
> backtrace?

Program received signal SIGABRT, Aborted.
0xf57fe416 in __kernel_vsyscall ()
(gdb) bt
#0  0xf57fe416 in __kernel_vsyscall ()
#1  0xb7e45781 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7e48bb2 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb7e7be75 in ?? () from /lib/i686/cmov/libc.so.6
#4  0xb7e85f71 in ?? () from /lib/i686/cmov/libc.so.6
#5  0xb7e877c8 in ?? () from /lib/i686/cmov/libc.so.6
#6  0xb7e8a8ad in free () from /lib/i686/cmov/libc.so.6
#7  0x080999a5 in zfree (p=0x8108240, sz=92) at mem.c:1719
#8  0xb7ba7666 in freecompctl (cc=0x8108240) at compctl.c:141
#9  0xb7baad43 in bin_compctl (name=0xb7c166f8 "compctl", 
argv=0xbffff294, 
    ops=0xbffff2d4, func=0) at compctl.c:1591
#10 0x08055b16 in execbuiltin (args=0xb7c166d0, bn=0xb7bb3524) at 
builtin.c:450
#11 0x080701c7 in execcmd (state=0xbffff940, input=0, output=0, how=18, 
    last1=2) at exec.c:3266
#12 0x0806bc74 in execpline2 (state=0xbffff940, pcode=131, how=18, 
input=0, 
    output=0, last1=0) at exec.c:1677
#13 0x0806b0c6 in execpline (state=0xbffff940, slcode=4098, how=18, 
last1=0)
    at exec.c:1462
#14 0x0806a908 in execlist (state=0xbffff940, dont_change_job=0, 
exiting=0)
    at exec.c:1245
#15 0x0806a388 in execode (p=0xb7c16648, dont_change_job=0, exiting=0, 
    context=0x80da3f7 "toplevel") at exec.c:1057
#16 0x08084c8c in loop (toplevel=1, justonce=0) at init.c:185
#17 0x08087d44 in zsh_main (argc=2, argv=0xbffffaa4) at init.c:1617
#18 0x0805512f in main (argc=2, argv=0xbffffaa4) at ./main.c:93
-- 
Nicholas Riley <njriley@illinois.edu>

Re: compctl crash

[Bart Schaefer]

On Apr 18,  5:01pm, Nicholas Riley wrote:
}
} I misunderstood the documentation for compctl, so I tried this:
} 
} compctl +
} 
} This crashes zsh back to at least 4.3.9 and up to the current version in 
} Git.  I had thought it would reset all the compctl-defined completions.

No, it's just supposed to list all the completions, like "compctl" with
no arguments at all.

There is indeed a double free.  There are only two calls to get_compctl()
in the source, and as far as I can tell neither of them really wants to
have it free an object passed in by the caller.  The value of "cl" is
always false, too, so there's a lot of dead code here.

diff --git a/Src/Zle/compctl.c b/Src/Zle/compctl.c
index 0143370..ab1857c 100644
--- a/Src/Zle/compctl.c
+++ b/Src/Zle/compctl.c
@@ -398,7 +398,6 @@ get_compctl(char *name, char ***av, Compctl cc, int first, int isdef, int cl)
 	if (cl)
 	    return 1;
 	else {
-	    freecompctl(cc);
 	    cclist = COMP_REMOVE;
 	    return 0;
 	}

Re: compctl crash

[Nicholas Riley]

In article <130418165936.ZM8756@torch.brasslantern.com>,
 Bart Schaefer <schaefer@brasslantern.com> wrote:

> No, it's just supposed to list all the completions, like "compctl" with
> no arguments at all.

Thanks, that makes sense.  (I had no reason to clear everything.)

And now it works, too!
-- 
Nicholas Riley <njriley@illinois.edu>