Re: Bug#459896: Segfaults in "apt-c(" completion

Re: Bug#459896: Segfaults in "apt-c(" completion

[Clint Adams]

On Wed, Jan 09, 2008 at 01:20:04PM +0100, Loïc Minier wrote:
>  while typo-ing I crashed zsh as follows, reproduced with a new user,
>  withing gdb, with zsh-dbg installed:
>  bee% autoload -U compinit
>  bee% compinit
>  bee% apt-c(^I
>     (that's "apt-c" + "(" + tab)
> 
>  Program received signal SIGSEGV, Segmentation fault.
>  0x080a1d23 in pattryrefs ()
> (gdb) bt full
> #0  0x080a1d23 in pattryrefs ()
> No symbol table info available.
> #1  0x080a25c8 in pattry ()
> No symbol table info available.
> #2  0x08097354 in scanparamvals ()
> No symbol table info available.
> #3  0xb7b69cc6 in scanpmcommands (ht=0x81a7808, 
>     func=0x8097200 <scanparamvals>, flags=42)
>     at ../../../Src/Modules/parameter.c:265
>         pm = {node = {next = 0x0, nam = 0x80edd58 "yacc", flags = 0}, u = {
>     data = 0x0, arr = 0x0, str = 0x0, val = 0, valptr = 0x0, dval = 0, 
>     hash = 0x0}, gsu = {s = 0xb7b6b790, i = 0xb7b6b790, f = 0xb7b6b790, 
>     a = 0xb7b6b790, h = 0xb7b6b790}, base = 0, width = 0, env = 0x0, 
>   ename = 0x0, old = 0x0, level = 0}
>         i = 0
>         hn = (HashNode) 0x80edd40
> #4  0x08074ae2 in scanmatchtable ()
> No symbol table info available.
> #5  0x08074b3c in scanhashtable ()
> No symbol table info available.
> #6  0x080949ca in paramvalarr ()
> No symbol table info available.
> #7  0x08094a5e in ?? ()

Thanks.

Re: Bug#459896: Segfaults in "apt-c(" completion

[Peter Stephenson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

Clint Adams wrote:
> On Wed, Jan 09, 2008 at 01:20:04PM +0100, Loïc Minier wrote:
> >  while typo-ing I crashed zsh as follows, reproduced with a new user,
> >  withing gdb, with zsh-dbg installed:
> >  bee% autoload -U compinit
> >  bee% compinit
> >  bee% apt-c(^I
> >     (that's "apt-c" + "(" + tab)

Doesn't happen here, but in any case I suspect this is some quite basic
problem since the "(" forces the shell to complete all possible commands
after it.  So it's simply searching the entire set of tables for things
that can occur in command position.  It's probably some memory
allocation thing.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: Bug#459896: Segfaults in "apt-c(" completion

[Clint Adams]

On Wed, Jan 09, 2008 at 05:35:30PM +0000, Peter Stephenson wrote:
> Doesn't happen here, but in any case I suspect this is some quite basic
> problem since the "(" forces the shell to complete all possible commands
> after it.  So it's simply searching the entire set of tables for things
> that can occur in command position.  It's probably some memory
> allocation thing.

More info from valgrind:

==7792== Invalid read of size 4
==7792==    at 0x80A1D23: pattryrefs (pattern.c:1873)
==7792==    by 0x80A25C7: pattry (pattern.c:1824)
==7792==    by 0x8097353: scanparamvals (params.c:517)
==7792==    by 0x47D3CC5: scanpmcommands (parameter.c:265)
==7792==    by 0x8074AE1: scanmatchtable (hashtable.c:381)
==7792==    by 0x8074B3B: scanhashtable (hashtable.c:444)
==7792==    by 0x80949C9: paramvalarr (params.c:551)
==7792==    by 0x8094A5D: getvaluearr (params.c:569)
==7792==    by 0x80955AA: getarg (params.c:1305)
==7792==    by 0x8096601: getindex (params.c:1591)
==7792==    by 0x80977CF: fetchvalue (params.c:1808)
==7792==    by 0x80AB2E3: stringsubst (subst.c:1912)
==7792==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==7792==
==7792== Process terminating with default action of signal 11 (SIGSEGV)
==7792==  Access not within mapped region at address 0x0
==7792==    at 0x80A1D23: pattryrefs (pattern.c:1873)
==7792==    by 0x80A25C7: pattry (pattern.c:1824)
==7792==    by 0x8097353: scanparamvals (params.c:517)
==7792==    by 0x47D3CC5: scanpmcommands (parameter.c:265)
==7792==    by 0x8074AE1: scanmatchtable (hashtable.c:381)
==7792==    by 0x8074B3B: scanhashtable (hashtable.c:444)
==7792==    by 0x80949C9: paramvalarr (params.c:551)
==7792==    by 0x8094A5D: getvaluearr (params.c:569)
==7792==    by 0x80955AA: getarg (params.c:1305)
==7792==    by 0x8096601: getindex (params.c:1591)
==7792==    by 0x80977CF: fetchvalue (params.c:1808)
==7792==    by 0x80AB2E3: stringsubst (subst.c:1912)
==7792==
==7792== ERROR SUMMARY: 11 errors from 7 contexts (suppressed: 75 from 1)
==7792== malloc/free: in use at exit: 943,011 bytes in 29,311 blocks.
==7792== malloc/free: 40,321 allocs, 11,010 frees, 3,810,434 bytes allocated.
==7792== For counts of detected errors, rerun with: -v
==7792== searching for pointers to 29,311 not-freed blocks.
==7792== checked 1,294,940 bytes.
==7792==
==7792== LEAK SUMMARY:
==7792==    definitely lost: 312 bytes in 22 blocks.
==7792==      possibly lost: 0 bytes in 0 blocks.
==7792==    still reachable: 942,699 bytes in 29,289 blocks.
==7792==         suppressed: 0 bytes in 0 blocks.
==7792== Rerun with --leak-check=full to see details of leaked memory.

Re: Bug#459896: Segfaults in "apt-c(" completion

[Peter Stephenson]

On Wed, 9 Jan 2008 15:57:32 -0500
Clint Adams <clint@zsh.org> wrote:
> On Wed, Jan 09, 2008 at 05:35:30PM +0000, Peter Stephenson wrote:
> > Doesn't happen here, but in any case I suspect this is some quite basic
> > problem since the "(" forces the shell to complete all possible commands
> > after it.  So it's simply searching the entire set of tables for things
> > that can occur in command position.  It's probably some memory
> > allocation thing.
> 
> More info from valgrind:
> 
> ==7792== Invalid read of size 4
> ==7792==    at 0x80A1D23: pattryrefs (pattern.c:1873)

That means the pattern prog passed down is invalid.  The previous stack
trace suggests it's come from scanning a hash.  It looks to me like there's
a pointer to a pattern prog being left flailing in some circumstances...
I don't see how this can be the root cause since scanprog isn't tested
to see if it's NULL, it's just used based on the SCANPM flags.  So they may
be set or used wrongly.

Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.140
diff -u -r1.140 params.c
--- Src/params.c	27 Dec 2007 16:00:55 -0000	1.140
+++ Src/params.c	10 Jan 2008 10:05:59 -0000
@@ -1308,8 +1308,10 @@
 					  SCANPM_KEYMATCH))))) {
 		    *inv = (v->flags & VALFLAG_INV) ? 1 : 0;
 		    *w = v->end;
+		    scanprog = NULL;
 		    return 1;
 		}
+		scanprog = NULL;
 	    } else
 		ta = getarrvalue(v);
 	    if (!ta || !*ta)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070