I wrote:
> It's fairly easy to reproduce in the regression database:
> type "\d ten<TAB>". I'm not sure what the triggering condition
> is exactly, because some seemingly-similar cases don't fail,
> for instance "\d test<TAB>" works as expected, ditto "\d t<TAB>".
It turns out that the problem occurs when there are exactly 9 + 10*N
possible completions, for any N>=0. There's an off-by-one logic bug
in libedit that results in a memory stomp because it forgets to enlarge
an array before storing a terminating null pointer in it.
The upstream netbsd sources incorporated a fix some time ago:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/readline.c.diff?r1=1.82&r2=1.83&sortby=date&f=h
with credit to Caleb Welton at Greenplum --- I wonder if he found it
because of psql failing? Apple hasn't incorporated this fix as of
OS X 10.6.3, however.
What's slightly more distressing is that the same source file
(readline.c) appears to have at least two other occurrences of the same
broken array-enlargement coding pattern, which were *not* fixed.
I've reported this to Apple but I'm not real sure where to file NetBSD
bugs. Anybody want to yank the BSD guys' chain about the other errors?
regards, tom lane