[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;
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- 'complete' bug with duplicated 'name' segfaults,
Erik Soe Sorensen <=