From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3) with ESMTP id UAA26442 for <mason@werple.mira.net.au>; Wed, 8 May 1996 20:07:34 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id FAA01891; Wed, 8 May 1996 05:44:17 -0400 (EDT)
Resent-Date: Wed, 8 May 1996 05:44:17 -0400 (EDT)
From: Hrvoje Niksic <hniksic@gnjilux.cc.fer.hr>
Message-Id: <199605080944.LAA04529@gnjilux.cc.fer.hr>
Subject: compctl bug with beta17 on Linux
To: zsh-workers@math.gatech.edu
Date: Wed, 8 May 1996 11:44:30 +0200 (MET DST)
Content-Type: text
Resent-Message-ID: <"1U5IR1.0.TT.hp6an"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1007
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

Hi!

I've found a serious bug that causes zsh-2.6beta17 (but also beta14 and
probably lots of others) to dump core on Linux box with uname -a output:
Linux gnjilux.cc.fer.hr 1.3.98 #1 Wed May 8 03:52:40 MET DST 1996 i486


In some cases zsh coredumps when programmable completion is set, like in:
compctl -g '*(D-/)' cd

and
cd /home/p[TAB]

where the file/dir beginning with 'p' doesn't exist, it coredumps. It fails
always on this one, but in other cases it doesn't (like cd /tmp/x[TAB] when
there's no 'x' in /tmp). The problem repeats in some other cases, like in
cd /proc/<something>[TAB], which should mean that the problem is not at
Linux's side. The problem disappears if cd is not compctl-ed.

gdb shows that the shell fails in zle_tricky.c, in the second call of
get_ccompctl, where the cmdstr contains garbage (instead of "cd"), and
causes declaration char *cmd = dupstring(cmdstr) to coredump in strcpy.

Further analysis shows that cmdstr (or at least the contents of the memory
it points to) gets garbled when newlinklist() is called in zle_tricky, line
2174,
fmatches = newlinklist()

The contents cmdstr points to is garbled in alloc, which might show the bug
in allocation routines.

Zsh allocation routines were not used.