Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:
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


pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group