[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

'complete' bug with duplicated 'name' segfaults

From: Erik Soe Sorensen
Subject: 'complete' bug with duplicated 'name' segfaults
Date: Fri, 11 Apr 2003 18:48:54 +0200

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib -O2 
-DBIGBROTHER -DLOGSTR='/var/run/.%d'
uname output: Linux iceman 2.4.18-19.7.x #1 Thu Dec 12 09:00:42 EST 2002 i686 
Machine Type: i686-pc-linux-gnu

Bash Version: 2.05a
Patch Level: 0
Release Status: release

        The 'complete' builtin can't handle the situation when a 'name' is
        added more than once in a line, e.g.:
                  complete foo foo
    The problem is that the compspec data is refcounted to zero and
        hence freed, the second time progcomp_insert() is called on it.
        (This also means that 'complete bar foo foo' does not trigger the
        The error shows, the next time the compspec is used (by completion
        or by 'complete -p'), most likely as a segmentation fault.
                $ complete foo foo
                $ complete
        This should result in a segmentation fault.
        (Well, not in an ideal world it shouldn't, but here it does).

    In progcomp_insert(), the CS refcount should be incremented
    earlier to avoid premature free'ing:

+       cs->refcount++;
        item = hash_insert (cmd, prog_completes, 0);
        if (item->data)
          free_progcomp (item->data);
          item->key = savestring (cmd);
        item->data = cs;
-       cs->refcount++;
        return 1;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]