bug-bash
[Top][All Lists]
Advanced

[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 
unknown
Machine Type: i686-pc-linux-gnu

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

Description:
        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
        error.)
        The error shows, the next time the compspec is used (by completion
        or by 'complete -p'), most likely as a segmentation fault.
        
Repeat-By:
        Type:
                $ complete foo foo
                $ complete
        This should result in a segmentation fault.
        (Well, not in an ideal world it shouldn't, but here it does).

Fix:
    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);
        else
          item->key = savestring (cmd);
        item->data = cs;
-       cs->refcount++;
        return 1;





reply via email to

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