Re: BUG #5418: psql exits after using tab-completion with error message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Ben Madin <ben(at)ausvet(dot)com(dot)au>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5418: psql exits after using tab-completion with error message
Date: 2010-04-15 04:13:51
Message-ID: 22441.1271304831@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2010-04-15 05:58:41 Re: Bug in CREATE FUNCTION with character type (CONFIRMED BUG)
Previous Message Bruce Momjian 2010-04-15 02:58:00 Re: BUG #5420: pg_attribute broken